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

[IT Free Day] PHP và curl_multi_exec()

Trải nghiệm ngày IT Free Day với một câu hỏi thường trực trong đầu -_-. Cũng không thể gọi đúng nghĩa là Free Day được.

Anyway, trở lại câu hỏi về hàm curl_multi_exec.

do {
      $multi_exec_handle = curl_multi_exec ($this -> curl_parent, $active);
} while ($active > 0);

Ba dòng code này có thể được tìm thấy trong cài đặt của một thư viện của CodeIgniter cho chức năng xử lý multi-curl [3].

Hàm curl_multi_exec nhằm mục đích cố gắng download nhiều trang (webpages dưới dạng HTML hoặc feeds dưới dạng XML) cùng một lúc, song song và độc lập với nhau.

Hàm curl_multi_exec nhận vào hai tham số:

  1. Tham số thứ nhất (ở đâu là $this -> curl_parent): một multi-handler tạo bởi hàm curl_multi_init() ở trước đó, giá trị kiểu resource.
  2. Tham số thứ hai $active: số lượng handler mà hàm đang làm việc, giá trị kiểu int. Ví dụ,  nếu bạn đang xử lý 5 URLs với muti-hander này, hàm curl_multi_exec sẽ trả về giá trị $active = 5 nếu nó đang làm việc với cả 5 URLs, và sau đó mỗi khi xử lý xong một URL, giá trị của $active sẽ được giảm xuống cho đến khi về 0.

Hàm curl_multi_exec trả về một giá trị kiểu int, và có thể nhận các giá trị sau:

  • CURLM_CALL_MULTI_PERFORM (-1): Nghĩa là bạn nên gọi hàm curl_multi_exec() một lần nữa bởi vẫn còn dữ liệu để xử lý.
  • CURLM_OK (0): Nghĩa là mọi việc đều tốt!!! Điều nó ám chỉ là có thể vẫn còn giá trị nhưng nó chưa đến.
  • Một trong các error codes sau: CURLM_BAD_HANDLE, CURLM_OUT_OF_MEMORY, CURLM_INTERNAL_ERROR, or CURLM_BAD_SOCKET. Error code ám chỉ rằng chúng ta cần dừng xử lý.

Với đoạn code 3 dòng của chúng ta, trong điều kiện lý tưởng, vòng lặp sẽ thoát khi giá trị $active bằng 0 (hoặc bằng CURLM_OK). Nhưng chuyện gì sẽ xảy ra nếu trong quá trình xử lý có điều bất thường xảy ra (lỗi mạng, …)? Giá trị của $active sẽ không bao giờ là CURLM_OK và chúng ta sẽ rơi vào vòng lặp vô hạn.

Nhiều cài đặt của hàm này là sẽ đợi cho tất cả các request được hoàn thiện trước khi xử lý chúng. Như vậy khi có quá nhiều request cần xử lý cùng lúc, chúng ta phải đợi cho đến lúc request CHẬM NHẤT được hoàn thiện, dẫn đến việc tốn thời gian đợi không đáng có.

Thêm nữa, khi chạy vòng lặp này, nó thường chiếm dụng CPU (100%) cho đến khi vòng lặp hoàn thành.

Trang manual của hàm này cung câp một đoạn code mẫu như sau (sử dụng hai lần vòng lặp do while giống hệt nhau)

<?php
 $active = NULL;
 do {
      $ret = curl_multi_exec($multi, $active);
 } while ($ret == CURLM_CALL_MULTI_PERFORM);

while ($active && $ret == CURLM_OK) {
       if (curl_multi_select($multi) != -1) {
      do {
            $mrc = curl_multi_exec($multi, $active);
      } while ($mrc == CURLM_CALL_MULTI_PERFORM);
      }
 }
?>

Vòng lặp do while đầu tiên chịu trách nhiệm làm sạch bộ đệm. Vòng lặp do while thứ hai có trách nhiệm đợi thêm dữ liệu và sau đó lấy về dữ liệu này. Điều này dẫn đến cái gọi là blocking I/O, chúng ta block sự thực thi phần còn lại của chương trình cho đến khi Network I/O được hoàn thiện.

Ý nghĩa của vòng lặp while như sau:

(while): Chừng nào vẫn còn kết nối và mọi thứ trông có vẻ ổn … 

    (if) Nếu network socket có vài dữ liệu… 

         (do/while) Xử lý dữ liệu chừng nào hệ thống nói rằng nên dừng lại

Vấn đề bảo mật trong PHP

Tìm hiểu rộng ra về hàm curl_multi_exec, có một vấn đề liên quan đến bảo mật. Khi cấu hình PHP, chúng ta cần lưu ý phải tắt (disable) một số hàm nguy hiểm có thể bị hacker lợi dụng để khai thác website, trong đó có hàm curl_multi_exec.

Danh sách các hàm nguy hiểm cần tắt:

  • exec
  • passthru
  • shell_exec
  • system
  • symlink
  • proc_open
  • popen
  • curl_exec
  • curl_multi_exec
  • parse_ini_file
  • show_source

Tắt các hàm này bằng cách thêm dòng sau vào file php.ini

disable_functions = exec, passthru, shell_exec, system, symlink, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source

Tham khảo

  1. Manual of Function curl_multi_exec: http://php.net/manual/en/function.curl-multi-exec.php
  2. Cách tắt hàm nguy hiểm của PHP (disable_functions) CentOS : https://powernet.vn/knowledgebase/283-Cach-tat-ham-nguy-hiem-cua-PHP-disablefunctions-CentOS.html
  3. Codeigniter library for multi-curl functionality : https://github.com/chadhutchins/codeigniter-mcurl/blob/master/application/libraries/mcurl.php
  4. PHP and curl_multi_exec: http://technosophos.com/2012/10/26/php-and-curlmultiexec.html

 

Đồ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.

 

Stress in English

Quy tắc về trọng âm câu:

  • Từ 2 âm tiết, trọng âm thường rơi vào từ đầu (‘happy, ‘dwindle). Tuy nhiên, nếu âm tiết đầu là một tiền tố thì trọng âm rơi vào âm tiết thứ hai (dis’like, pro’long).
  • Từ 3 âm tiết trở lên, trọng âm rơi vào âm tiết thứ ba tính từ phải sang (phi’losophy, bio’logical). Tuy nhiên, nếu tận cùng bằng -ion hoặc -ic(s) thì trọng âm rơi vào âm tiết đứng ngay sát trước nó (trans’lation, auto’matic)

Expression in English

When we do a writing, we usually use some general lazy expression (for ex. a good student, a slow computer …). It should be avoid and could be replaced by an interesting corresponding one. These are following some substitutions:

1. Good -> Rewarding or Satisfying

2. Slow -> Retard

3. Many -> Several (Not sure)

Informal writing: a simple verb with a preposition (for ex. to look into, to look after) is the least formal choice and is commonly used in informal spoken language notes, emails and postcards.

Formal writing: words borrowed into English from other languages, especially Latin and Greek, are quite formal, or high register. These words are used in technical, scientific, medical, psychological and philosophical writings.

  • Many words ending in -ion are borrowed from Latin (such as: discussion, examination, explanation, information, instruction, investigation, presentation)

+ Distinguish ei/ie

Write I before E

Except after C

Or when sounded like AY

As in Neighbour and Weigh

——————

References:

1. Study English Book