Database Replication

I.Một số thuật ngữ liên quan đến đồng bộ dữ liệu

  • Nhân bản (replication): liên quan đến việc chia sẻ thông tin cũng như đảm bảo sự nhất quán (consistency) giữa những tài nguyên dự phòng/dư thừa (redundant) để tăng độ tin cậy, fault-tolerance, hay khả năng truy cập. Tài nguyên ở đây có thể là: phần mềm hoặc phần cứng, gọi chung là node.
    • Nhân bản dữ liệu (data replication): cùng một dữ liệu được lưu trữ trên nhiều thiết bị.
  • Faut-tolerance: thuộc tính cho phép hệ thống tiếp tục hoạt động đúng trong trường hợp có lỗi xảy ra với một vài thành phần của hệ thống.
  • Failover: chuyển sang dùng hệ thống dự phòng / hệ thống chờ khi hệ thống đang hoạt động có sự cố xảy ra hoặc bị kết thúc bất thường.
  • Nhân bản kiểu đồng bộ và bất đồng bộ (Synchronous vs Asynchronous Replication)
    • Sync Replication: đảm bảo rằng những thay đổi trên một node của cluster sẽ xảy ra trên những node khác, gần như tại cùng một thời điểm.
    • Async Replication: không đảm bảo về độ trễ khi cập nhật những thay đổi trên một node sẽ xuất hiện trên node khác. Điều này dẫn tới khả năng khi một node bị crash, một vài sự thay đổi cuối cùng có thể bị mất, không được đồng bộ sang những node khác.
    • Về mặt lý thuyết, Sync Replication có nhiều điểm lợi hơn Async Replication
      • Sync Replication luôn high-availability. Không có mất dữ liệu khi một node bị crash và những bản sao dữ liệu là nhất quán.
      • Transactions có thể được thực thi song song ở tất cả các nodes.
      • Sync Replication có thể đảm bảo tính nhân quả (causality) trong toàn cluster.
      • Tuy nhiên, trong thực tế, synchronous replication được cài đặt theo cách truyền thống dựa theo cấu trúc nổi tiếng “2-phase commit” hoặc khóa phân phối (distributed locking), mà đã được chứng minh là rất chậm. Hiệu suất thấp và độ phức tạp của cài đặt synchronous replication dẫn đến tình trạng nhân bản kiểu không đồng bộ (asynchronous replication) vẫn thống trị khi tính đến vấn đề hiệu suất.
  • Eager Replication vs Lazy Replication
    • Thuật ngữ Eager Replication hay Lazy Replication đôi khi có thể được đồng nhất  với Synchronous/Asynchronous Replication. Có một sự khác nhau nhỏ: thay vì tập trung vào vấn đề xử lý transactions một cách đồng bộ, hai thuật ngữ này ám chỉ rằng các nodes, các bản sao (replicas) cuối cùng đều phải đảm bảo sự nhất quán. Điều này có nghĩa là phải đảm bảo transactions theo cùng một thứ tự, không nhất thiết phải  đồng bộ gần như tức thì tại thời điểm có sự thay đổi.
    • Theo đó, eager replication có thể coi như ở giữa Sync và Async Replication: cho phép một node bị lag so với node khác trong khi vẫn tránh được sự sai khác giữa các nodes.
    • Eager replication phải nhân bản dữ liệu transaction trước khi xác nhận commit, trong khi Lazy replication nhân bản dữ liệu ở đâu đó sau khi commit, vì vậy nguy cơ xung đột tăng cao.
    • Lazy replication luôn luôn là Async và không tránh đc sự sai khác.
  • Replication Topologies
    • Master-Slave
    • Master-Master (2 hệ thống / nodes)
    • Multi-Master (>2 hệ thống / nodes)
  • Thuật ngữ liên quan đến Galera Cluster
    • wsrep: Write Set REPlication
    • SST: State Snapshot Transfer
    • IST: Incremental State Transfer
    • Donor node: một db server (một node) đã tồn tại trong hệ thống và có thể sử dụng như đầu mối để các node mới kết nối vào cluster
    • Joining node: một db server (một node) đang kết nối vào cluster

II. Cài đặt nhân bản dữ liệu trong một số hệ quản trị dữ liệu

1. MySQL/Maria (Galera)

Một đặc điểm thú vị của MariaDB là built-in hỗ trợ Galera Cluster.

Xem phần III bên dưới

2. Oracle

3. Postgres-R

4. Microsoft SQL

5. MongoDB / CouchDB / RethinkDB

replica-set-read-write-operations-primary

Nhân bản dữ liệu trong MongoDB sử dụng cơ chế Asynchoronous Replication liên quan đến 3 thành phần :

  1. Node chính (primary node): chỉ có duy nhất một node chính
  2. Node phụ (secondary node)
  3. Trọng tài (arbiter)

Một tập bản sao (replica set) là một tập instance của mongod duy trì một tập dữ liệu giống nhau. Chỉ một thành viên được coi là node chính (primary node), trong khi các node khác được coi là node phụ (secondary node).

Nếu node chính có vấn đề gì (unavailable), một node phụ đủ điều kiện sẽ tự đề cử bản thân nó thành node chính mới.

Một trọng tài (arbiter) sẽ luôn luôn là trọng tài, trong khi một node chính có thể bước xuống để trở thành node phụ và ngược lại một node phụ có thể tiến lên trở thành node chính.

Cơ chế đồng bộ trong MongdoDB là tự động fail-over: khi node chính không giao tiếp/kết nối với những thành viên khác trong khoảng thời gian > 10s, một node phụ đủ điều kiện sẽ tự đề cử nó để trở thành node chính. Node phụ đầu tiên đề cử và nhận được phần lớn đồng ý của các thành viên khác sẽ trở thành node chính

III. Multi-Master Replication sử dụng Galera Cluster

1. Giới thiệu

Galera cluster được sử dụng bởi nhiều công ty lớn như Wikipedia, Facebook, Google, cũng như bởi hàng nghìn users trong nhiều lĩnh vực: e-commerce, telecom, gaming, insurance, healthcare, media, marketing, advertising, travel, university, software-as-service, Paas, Iaas, …

Nó được cài sẵn trong nhiều phiên bản Linux và OpenStack gần đây. Thống kê cho thấy 30% người dùng OpenStack đang sử dụng Galera Cluster cho HA. Phiên bản hiện tại của Galera wsrep provider là 25.3.15

galera_replication1

Video giới thiệu Galera

Galera cluster cho phép nhân bản kiểu multi-master và tập trung mạnh vào sự nhất quán của dữ liệu.

Galera cluster được hỗ trợ bởi MySQL bản >= 5.5 và MariaDB bản >= 5.5.

  • Trong bản MariaDB 5.5 và 10.0, Galera Cluster là một gói riêng được cài đặt thêm chứ không phải là gói chuẩn của MariaDB Server.
  • Trong MariaDB 10.1, hai gói MariaDB Server và MariaDB Galera Server được kết hợp với nhau kèm theo những gói phụ thuộc được cài đặt tự động khi cài MariaDB, tuy nhiên Galera chỉ hoạt động khi đã được cấu hình bật lên giống như một plugin.
  • MariaDB Galera Cluster là một bản vá của MySQL-wsrep thực hiện bởi Codership và hiện tại chỉ hỗ trợ Linux

Galera hỗ trợ Cloud (như AWS zones) và WAN.

Mỗi node trong Galera cluster đều là master:

  • Không còn quan hệ kiểu chính-phụ (primary-secondary)
  • Không cần phải promote một secondary thành master khi có master failure

Mọi bản sao đều chứa TOÀN BỘ tập dữ liệu và nhất quán:

  • Client có thể query dữ liệu trên tất cả các nodes
  • Có thể response bất kỳ read request mà không có độ trễ
  • Loại bỏ latency cho nhiều hoạt động

Trong trường hợp có vấn đề xảy ra với một node, hệ thống sẽ tự động failover.

Quá trình đồng bộ dữ liệu xảy ra ở thời điểm commit:

  • Độ trễ của kế nối mang có thể làm chậm quá trình commit, nhưng tránh được disk I/O
  • Conflicts được phát hiện tại thời điểm commit

Galera cluster sử dụng row-based binary log events (không phải binary log files).

Galera có thể được cài đặt để đồng bộ chỉ một hay vài tables hoặc databases sử dụng những bộ lọc (replication filters).

  • Hai bộ lọc được khuyến khích sử dụng trong Galera là replicate-do-db, replicate-ignore-db, cho cả hai loại engine InnoDB và MyISAM.
  • Ngược lại, những bộ lọc sau không được khuyến khích sử dụng: binlog-do-db , binlog-ignore-db, replicate-wild-do-db, replicate-wild-ignore-db.

2. Chức năng và phương thức đồng bộ

Chức năng của Galera Replication được cài đặt như một thư viện chia sẻ và có thể được link với bất kỳ hệ thống xử lý transaction nào nếu hệ thống này cài đặt wsrep API hooks.

Thư viện Galera Replication là một stack giao thức cung cấp chức năng cho việc chuẩn bị, nhân bản và áp dụng các tập ghi transaction. Nó bao gồm các modules:

  • wsrep API: xác định giao diện, trách nhiệm cho DBMS và nhà cung cấp replication
  • wsrep hooks: là việc tích hợp wsrep bên trong engine DBMS
  • Galera provider: cài đặt wsrep API cho thư viện Galera
  • Tầng certification: chịu trách nhiệm chuẩn bị tập ghi (write sets) và thực hiện việc chứng nhận
  • Replication: quản lý giao thức nhân bản và cung cấp toàn bộ khả năng ordering
  • GCS framework: cung cấp kiến trúc plugin cho các hệ thống giao tiếp nhóm. Nhiều cài đặt GCS có thể được thích nghi (adapt), được thử nghiệm với những cài đặt in-house như: vsbes gemini.

Galera sử dụng 3 phương thức để đồng bộ dữ liệu: mysqldump, rsync, xtrabackup-v2

  1. rsync: là phương thức mặc định và yêu cầu ít thời gian setup nhất. Điểm yếu của nó là node đầu mối (donor node) sẽ bị block với tất cả các hoạt động trong lúc đang thực hiện SST.
  2. mysqldump: chuyển dữ liệu dưới dạng các lệnh SQL INSERT. Mỗi lệnh này sẽ tốn thời gian để thực thi trên các node đang join vào nếu kích thước của tập dữ liệu là đáng kể. Có một vài kỹ thuật để tăng hiệu suất insert, tuy nhiên nó không thể loại bỏ cản trở lớn nhất là dữ liệu được chuyển theo kiểu row-by-row thay vì file-by-file.
  3. xtrabackup-v2: sử dụng công cụ Percona XtraBackup để thu về một snapshot không bị block (non-blocking snapshot) của node đầu mối (donor node) và sau đó sử dụng snapshot đó để khởi động node mới join vào. Điều này yêu cầu cài đặt phức tạp hơn một chút, nhưng node đầu mối hầu như luôn sẵn sàng cho việc query trong suốt quá trình xử lý. Đây là phương thức nên sử dụng để cài đặt trong nếu chúng ta muốn loại bỏ thời gian chết của node đầu mối.

Galera sử dụng các cổng sau:

  1. Cổng 3306 để kết nối với MySQL client và State Snapshot Transfer (SST) nếu sử dụng phương thức mysqldump để đồng bộ
  2. Cổng 4567 dùng cho replication traffic, multicast. Sử dụng cả 2 giao thức UDP và TCP
  3. Cổng 4568 dùng cho Incremental State Transfer
  4. Cổng 4444 dùng cho State Snapshot Transfer nếu sử dụng phương thức rsync để đồng bộ

3. Hướng dẫn setup một Galera Cluster

Tham khảo chi tiết các bước tại link

Tham khảo

  1. Wiki about Replication: https://en.wikipedia.org/wiki/Replication_(computing)#DATABASE

  2. MySql Multi-Master Replication with Galera https://www.sebastien-han.fr/blog/2012/04/01/mysql-multi-master-replication-with-galera/
  3. Setup Galera Cluster with MariaDB 10.0 in CentOS https://www.unixmen.com/setup-mariadb-galera-cluster-10-0-centos/
  4. Getting started with Galera Cluster in MariaDB https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/
  5. Tutorial of Galera Cluster in MySql http://severalnines.com/tutorials/clustercontrol-mysql-galera-tutorial
  6. Documentation of Galera Cluster http://galeracluster.com/documentation-webpages/?id=mysql_galera_configuration
  7. Installation of Galera Cluster in MariaDB http://tunnelix.com/mariadb-galera-cluster-installation/
  8. Migrating to Multi-Master Galera Cluster from Master-Slave MySQL Replication https://www.youtube.com/watch?v=u7H7C12vRpU
  9. Galera Cluster Installation and Quick Start Webinar video https://www.youtube.com/watch?v=YX3rn5Z5ToM
  10. Galera Cluster Installation and Quick Start Webinar slide http://www.slideshare.net/Codership/coderships-galera-cluster-installation-and-quickstart-webinar-march-2016-59361687
  11. Replication in MongoDB https://docs.mongodb.com/manual/replication/
  12. About Galera Replication https://mariadb.com/kb/en/mariadb/about-galera-replication/
  13. Database replication: a tale of research across communities, Kemme, Bettina and Alonso, Gustavo, 2010
  14. Terms and Definitions for Database Replication http://www.postgres-r.org/documentation/terms
  15. Galera cluster, MariaDB, CoreOS and Docker http://withblue.ink/2016/03/09/galera-cluster-mariadb-coreos-and-docker-part-1.html
  16. How to setup HAProxy as Load Balancer for MariaDB on CentOS 7 https://www.howtoforge.com/tutorial/how-to-setup-haproxy-as-load-balancer-for-mariadb-on-centos-7/
  17. MySQL multi-master replication with Galera https://www.sebastien-han.fr/blog/2012/04/01/mysql-multi-master-replication-with-galera/

  18. Standard Replication https://mariadb.com/kb/en/mariadb/standard-replication/
Advertisements

Đồng bộ dữ liệu Theo Mô Hình Master-Master Replication

1. Giới thiệu chung

Mô hình đồng bộ kiểu Master-Master cho phép mọi thay đổi trên db này được cập nhật trên db kia. Điều này sẽ khắc phục yếu điểm của mô hình Master-Slave, khi thay đổi trên Slave (trong trường hợp db Master không hoạt động phải chuyển sang db Slave) sẽ không được cập nhật trên db Master.

 

Impact Factor

Impact Factor (IF) of an academic journal is a measure reflecting the average number of citations to recent articles published in this journal [Wiki].

The impact factor of a journal represents the influence of a journal based on its number of citations. It is used as a metric to show the relative significance of a journal with respect to its field. If the impact factor of a journal is high, it implies the relevance of the journal when compared to other ones. It was stated first by Eugene Garfield and now it is considered as a major factor to judge a journal. [1]

Impact factor 2012 = Number of times the published articles of previous year were cited in journals  during this year / The total number of articles published last year

Top IF Journals (around 4.5) in Computer Science:

  • IEEE Communications Surveys and Tutorials
  • ACM Computing Surveys
  • Journal of Chemical Information and Modeling
  • IEEE Transactions on Pattern Analysis and Machine Intelligence
  • International Journal of Computer Vision

 

JCR: Journal Citation Reports

 

 

—————-

References:

  1. http://www.eexploria.com/impact-factors-of-computer-science-journals/

  2. http://www.scimagojr.com/journalrank.php?area=1700