Nhân rộng đồng bộ

 So sánh nhân rộng không đồng bộ và nhân rộng đồng bộ Nhân rộng không đồng bộ Nhân rộng đồng bộ Sử dụng phương pháp tiếp cận

không sẵn sàng, có nghĩa là các master server cập nhập cơ sở dữ liệu sau đó truyền các thông tin về việc cập nhập đến các slave server. Sau khi master server truyền các thông tin thì nó thông báo rằng hệ thống đã được đồng bộ. Nói các khác, khi một phiên cập nhập được xác nhận là thành công thì sẽ có một khoảng thời gian ngắn dữ liệu trên các nút khác nhau.

Sử dụng phương pháp tiếp cận sẵn sàng, có nghĩa là khi thực hiện việc cập nhập lên một nút thì tất cả các nút khác cũng đang thực hiện những thay đổi đó. Nói các khác, khi một phiên cập nhập được xác nhận là thành công thì dữ liệu trên tất cả các nút là giống nhau.

 Ưu điểm của nhân rộng đồng bộ

Về lý thuyết, nhân rộng đồng bộ có lợi thế hơn nhân rộng không đồng bộ ví dụ như:

 Tính sẵn sàng cao: Nhân rộng đồng bộ cung cấp cho cụm cơ sở dữ liệu tính sẵn sàng cao và đảm bảo dịch vụ sẵn sàng 24/7:

- Không mất dữ liệu khi nút bị hỏng. - Dữ liệu trên các nút luôn được đồng bộ.

- Không phức tạp, tốn thời gian cho chuyển đổi dự phòng.

 Hiệu xuất được cải thiện: Việc đồng bộ cho phép chúng ta có thể thực hiện các truy vấn trên tất cả các nút trong cụm song song với nhau -> tăng hiệu xuất làm việc.

 Tính nhất quán trên tất cả các nút: ví dụ như khi thực hiện truy vấn SELECT trên một nút sau khi đã thực hiện phiên cập nhập dữ liệu trên một nút khác thì sẽ thấy dữ liệu đã được cập nhập.

Hầu hết các phương pháp nhân bản đều là không đồng bộ, MySQL 5.5 đã có phương pháp Semi-sync Replication tốt hơn tuy nhiên việc sao lưu không đồng bộ có nghĩa là dữ liệu rất có thể bị mất. Đôi khi việc mất mát dữ liệu trở nên rất nghiêm trọng nếu như trong một hệ thống lớn.

25

Khi thực hiện việc thay đổi dữ liệu trên master server liên tục sẽ gây ra tình trạng slave server không bắt kịp những sự thay đổi này (slave lag). Tình trạng này sẽ làm giảm từ 50-80% hiệu xuất của hệ thống.

Hình 3.7 cho thấy mô hình master - slave dẫn đến việc đọc và ghi bị tách biệt, cần có chuyển đổi dự phòng. Các slave server có thể bị tách biệt, việc các slave server không đồng bộ dữ liệu với nhau có thể sảy ra.

Hình 3.1. Không đồng bộ giữa master và slave 3.2. Giới thiệu về giải pháp Multi master Replication

Nhân rộng cơ sở dữ liệu liên quan đến việc phải sao chép dữ liệu thường xuyên trên một máy chủ cơ sở dữ liệu khác. Tại sao chúng ta không nghĩ đến việc xây dựng một hệ thống nhân bản cơ sở dữ liệu như là một mô hình cơ sở dữ liệu phân tán, tất cả các nút chia sẻ cùng một loại thông tin. Hệ thống này cũng được biết đến như một cụm cơ sở dữ liệu. Khi đó các ứng dụng web hay các phần mềm máy tính không thấy được cấu trúc hệ thống nhưng vẫn có thể truy xuất, thao tác trên dữ liệu. Ý tưởng ở đây được đưa ra là giải pháp để xây dựng một hệ thống gồm nhiều máy chủ cơ sở dữ liệu và đều là master server.

Đến với giải pháp multi master chúng sẽ có những khác biệt. Multi master là một phương pháp sao lưu cơ sở dữ liệu. Nó cho phép dữ liệu được lưu trữ bởi một nhóm các server và việc cập nhập sẽ được thực hiện bởi bất kì thành viên nào trong nhóm. Tất cả các thành viên trong nhóm đều đáp ứng được các truy vấn dữ liệu từ client. Hệ thống multi master replication có trách nhiệm truyền thông tin khi có sự cập nhập dữ liệu được thực hiện trên một thành viên tới mỗi thành viên còn lại của nhóm

26

và giải quyết các xung đột có thể xảy ra giữa những thay đổi đồng thời được thực hiện bởi các thành viên khác nhau.

Hình 3.2. Mô hình đồng bộ Multi Master

Có thể nói mô hình multi master replication là một bước tiến mới trong việc đồng bộ sao lưu dữ liệu. Thế nhưng phương pháp multi master truyền thống vẫn có các nhược điểm như:

 Phức tạp và khó triển khai

 Việc ghi trên nhiều nút dẫn đến xung đột giữa các nút.

 Hiệu suất không cao, khả năng sẵn sàng kém hiệu quả.

Vì vậy phần tiếp theo của khóa luận sẽ trình bày phương pháp đồng bộ nhân rộng dữ liệu: Muilti master Replication trên MySQL sử dụng Galera.

3.3.Giới thiệu về Galera Cluster 3.3.1.Tổng quan 3.3.1.Tổng quan

Được phát triển vào năm 2003, lúc này Galera được gọi như là một cụm cơ sở dữ liệu MySQL với 3 server. Đến năm 2007 thì Galera bắt đầu được ứng dụng. Ban đầu Galera là một ứng dụng miễn phí, mã nguồn mở do Codership hỗ trợ và tư vấn. Sau này Percona XtraDB được phát triển dựa vào Galera, đây cũng là một giải pháp giống Galera, Percona XtraDB ra mắt vào năm 2012. Galera không phải của MySQL phát triển mà được phát triển của một hãng bên thứ 3 là Codership.

MySQL/Galera là một cụm cơ sở dữ liệu, trong đó bao gồm nhiều master server được đồng bộ với nhau sử dụng công cụ lưu trữ InnoDB. Khi sử dụng Galera Cluster, bạn có thể thực hiện việc đọc và ghi ở bất kì nút nào, nếu một nút bị hỏng cũng sẽ không ảnh hưởng gì tới quá trình hoạt động của các nút khác trong cụm. Các ứng dụng sẽ nhìn hệ thống như một cơ sở dữ liệu lớn chứ không phải nhiều cơ sở dữ liệu.

27  Ưu điểm

Bằng cách kết hợp các kinh nghiệm trong việc sao chép đồng bộ và các nghiên cứu mới nhất trong lĩnh vực này một nhóm nghiên cứu đã phát triển giải pháp Multi master Replication sử dụng Galera.

Galera cung cấp một số cải thiện đáng kể để nâng cao tính sẵn sàng cho hệ quản trị MySQL. Có những cách khác nhau để nâng cao tính sẵn sàng trong MySQL và một trong những cách đó được cài đặt sẵn trong Galera Cluster. Có thể nói lựa chọn Galera là một giải pháp đúng đắn bởi vì Galera Cluster có những ưu điểm sau:

 True multi-master: Đọc và viết trên bất kì nút nào và bất cứ khi nào.  Synchronous Replication: Nhân bản đồng bộ.

 No slave lag: Không có sự chậm trễ từ slave server, không mất dữ liệu khi một nút bị hỏng.

 Tightly Coupled: Tất cả các nút giữ cùng một trạng thái, không có sự khác biệt về dữ liệu trên các nút.

 Multi-threaded Slave: Đạt hiệu quả tốt hơn đối với khối lượng công việc bất kì.

 No Master-Slave Failover Operations or Use of VIP: Không hoạt động với mô hình có chuyển đổi dự phòng master-slave do vậy sẽ không có thời gian chậm chễ giữa các nút.

 Automatic Node Provisioning: Tự động nối nút khi nút đã sẵn sàng không cần phải sao chép cơ sở dữ liệu sau đó chép vào nút mới.

 Supports InnoDB: Hỗ trợ công cụ sao lưu InnoDB phổ biến.

Một cụm Galera tối thiểu bao gồm 3 nút. Vì nếu 1 nút có vấn đề (có thể về mạng hay về sự cố máy tính) thì hai nút còn lại sẽ có một nút làm đại diện và có thể tiến hành các thay đổi (insert, update, delete) trên nút này.

 So sánh Galera Cluster với MySQL (NDB) Cluster

Số liệu được lấy từ một số nghiên cứu của các chuyên gia hàng đầu trong lĩnh vực quản trị cơ sở dữ liệu:

Đồ thị biểu diễn thông lượng (số transaction/s) của 2 giải pháp (Hình 3.3).

Hình 3.3. Đồ thị biểu diễn thông lượng của Galera và NDB Thông lượng càng lớn càng tốt.

28

Hình 3.4 là biểu đồ so sánh thời gian phản hồi của 2 giải pháp.

Hình 3.4. Đồ thị biểu diễn thời gian phản hồi của Galera và NDB Thời gian phản hồi càng ít càng tốt

Tiếp theo là biểu đồ người sử dụng của 2 giải pháp Galera và NDB

Hình 3.5. Đồ thị so sánh số lượng người dùng của Galera và NDB

Dựa vào biểu đồ hình 3.5 có thể thấy Galera tốt hơn gấp 4 lần. Thật vậy hãy cùng quan sát:

Galera: Tốt hơn về:

 Tải tốt khi khối lượng công việc nhiều.  Dễ dàng cài đặt các thiết lập.

 Thân thiện với người sử dụng.  Đồng bộ ở mọi nơi.

MySQL (NDB) cluster:  Khó khăn khi tải nặng.

Có rất nhiều công ty lớn trên thế giới sử dụng Galera như trang web nổi tiếng ở Đức trang GuteFrage.net, hãng Promoht, hãng ComplyWorks….

29

 So sánh hiệu xuất hệ thống với phương pháp Semi-sync

Dữ liệu được tham khảo từ: Von erkan. (27.01.2014 22:46), “Benchmarking Galera Cluster.”Avaiable http://linsenraum.de/erkules_int/2014/01/benchmarking- galera-cluster.html (Accesed: 2015, April 21).

 Cấu hình hệ thống o Galera Nodes:

-Các máy ảo (OpenStack) được cung cấp bởi teuto.net -CPU: 4

-RAM: 4GB

-OS: CentOS 6.4-x86_64

-MySQL-server-5.6.14 wsrep 25.1-1.rhel6.x86_64 -Galera-25.3.2-1.rhel6.x86_64

Thí nghiệm sử dụng công cụ sysbench để đánh giá hiệu xuất của 2 giải pháp Galera và Semi-sync.

o Sysbench được cài đặt trên nút riêng:

-Cùng thông số kỹ thuật như các nút Galera -Sysbench 0.5

-Kiểm tra OLTP trên 5 bảng với mỗi bảng 1000000 hàng (khoảng 1.2GB) -Một lần chạy mất 60 giây

 Kết quả

Hình 3.6. Biểu đồ so sánh hiệu xuất 2 giải pháp

Dựa vào biểu đồ hình 3.6 có thể thấy hiệu xuất của giải pháp với Galera tốt hơn hẳn so với giải pháp Semi-sync. Có thể thấy ở vị trí sysbench threads = 128 thì số transaction của giải pháp Galera là gần 700 trong khi đó của giải pháp Semi-sync chỉ là gần 500 số chênh lệch khá lớn.

30

3.4. Nguyên lý hoạt động của giải pháp Multi master Replication sử dụng Galera

3.4.1.Thành phần cấu tạo của hệ thống

Giải pháp này sử dụng phương thức nhân rộng sẵn sàng. Các nút trong cluster đồng bộ với nhau bằng cách cập nhập các sự thay đổi trên master server. Có nghĩa là khi một giao dịch đã được xác nhận thành công thì tất cả các nút có cùng một giá trị. Quá trình này diễn ra bằng cách sử nhân bản write-set thông qua truyền thông nhóm.

Hình 3.7. Thành phần một cụm Galera  Kiến trúc của cụm Galera gồm có 4 thành phần chính:

Hình 3.8. Một nút trong cụm Galera

 Hệ thống quản lý dữ liệu (DBMS) Các máy chủ cơ sở dữ liệu. Các máy chủ cơ sở liệu trong cụm Galera có thể sử dụng các hệ quản trị cơ sở dữ liệu như MySQL, MariaDB hoặc Percona XtraDB.

31

 Wsrep API: cung cấp những công cụ cần thiết để nhân bản cơ sở dữ liệu. Wsrep API bao gồm:

- Wsrep hooks: tích hợp với các máy chủ cơ sở dữ liệu để nhân rộng write-set.

- Dlopen(): là một hàm mà cung cấp các dịch vụ cần thiết cho wsrep hooks.  Galera Replication Plugin: Chứa các plugin phục vụ chức năng nhân rộng

write-set.

 Group Communication plugins: là một hệ thống nhóm truyền thông có sẵn cho Galera Cluster

 Thiết kế chi tiết:  DBMS

Các máy chủ cơ sở dữ liệu có cài đặt các hệ quản trị cơ sở dữ liệu như MySQL, MariaDB hoặc Percona XtraDB.

 Wsrep API:

Wsrep API là một plugin nhân bản chung cho các cơ sở dữ liệu. Các wsrep API sử dụng một mô hình nhân bản và quan sát các máy chủ cơ sở dữ liệu để có một trạng thái. Trạng thái được đề cập ở đây là nội dung của cơ sở dữ liệu. Khi một máy chủ cơ sở dữ liệu có những thay đổi về nội dung dữ liệu thì trạng thái của các wsrep API cũng sẽ thay đổi. Các wsrep API sẽ đại diện cho những thay đổi trong trạng thái của cơ sở dữ liệu.

Từ một góc nhìn khác, cụm Galera xử lý những thay đổi trạng thái theo quy trình sau:

1. Trên một nút trong cụm, cơ sở dữ liệu thay đổi trạng thái.

2. Trong cơ sở dữ liệu, các wsrep hooks biên dịch các thay đổi và ghi vào write-set.

3. Dlopen(): cung cấp các dịch vụ cần thiết cho wsrep-hooks.

4. Các plugin Galera Replication xử lý xác nhận write-set và nhân bản cho các nút trong cluster.

ID giao dịch

Để giữ cho các nút có cùng trạng thái, các wsrep API sử dụng một ID cho mỗi giao dịch và dùng chung cho cả cụm hay được gọi là GTID. Nhờ vậy nó có thể xác định các thay đổi về trạng thái và xác định trạng thái hiện thời liên quan đến sự thay đổi trạng thái cuối cùng.

32 ID giao dịch gồm các thành phần

 State UUID: Một định danh duy nhất cho các trạng thái và trình tự của nó sau khi trải qua những lần thay đổi.

 Ordinal Sequence Number: các seqno và một chữ kí dạng số nguyên 64 bit sử dụng để biểu thị vị trí của những thay đổi trong chuỗi trình tự.

ID giao dịch dùng chung cho phép hệ thống có thể so sánh các trạng thái và thiết lập thứ tự cho những lần thay đổi trạng thái. Hệ thống có thể sử dụng nó để xác định có hay không một sự thay đổi đã được thực hiện và cho dù sự thay đổi này đã được thực hiện trên tất cả các nút.

o Wsrep hooks biên dịch và ghi các sự kiện trong giao dịch vào write-set. Như vậy write-set sẽ chứa các thay đổi trên cơ sở dữ liệu, các từ khóa chính của các hàng, ID giao dịch, ID của giao dịch trước đó.

Hình 3.9. Cấu trúc write-set

o Dlopen(): cung cấp các dịch vụ cần thiết cho wsrep-hooks.  Galera Replication Plugin

Galera Replication Plugin thi hành các wsrep API, nó hoạt động như các nhà cung cấp wsrep API cho các nút khác. Từ góc nhìn kĩ thuật các Galera Replication Plugin bao gồm các thành phần sau:

 Certification Layer: lớp này chuẩn bị write-set và thực hiện việc kiểm tra write- set có đảm bảo để áp dụng trên database được không.

 Replication Layer: lớp này quản lý giao thức nhân bản và cung cấp thứ tự thực hiện các trạng thái.

 Group Communication Framework: lớp này cung cấp một kiến trúc plugin cho hệ thống Group Communication để kết nối các nút trong cụm Galera Cluster.

 Group Communication Plugin

Các Group Communication Framework cung cấp kiến trúc dạng plugin cho hệ thống Gcomm khác nhau để kết nối các nút.

33

Galera Cluster được xây dựng ở bên trên hệ thống Group Communication. Hệ thống này thực hiện một phương pháp đồng bộ đó là đồng bộ ảo QoS. Đồng bộ ảo là thống nhất việc phân phối dữ liệu và các dịch vụ trong nhóm. Cung cấp thông tin một cách rõ ràng về hình thức vận chuyển.

Đồng bộ ảo đảm bảo tính thống nhất nhưng không đảm bảo tính đồng bộ về thời gian, điều đó là cần thiết cho hệ thống đa máy chủ. Để làm được điều này cụm Galera cần thực hiện việc kiểm soát thời gian cấu hình và thời gian của dòng chảy giao dịch trong nhóm.

Thêm vào đó các Group Communication Framework cũng cung cấp tổng số các giao dịch cần thực hiện từ nhiều nút trong cụm. Nó sử dụng điều này để tạo ra ID giao dịch chung cho cụm.

Ở cấp độ vận chuyển, cụm Galera là một đồ thị vô hướng đối xứng. Tất cả các nút kết nối với nhau thông qua một kết nối TCP. Theo mặc định TCP được sử dụng để cho các thành viên trong nhóm kết nối với nhau, nhưng cũng có thể sử dụng UDP multicast để nhân bản trong một mạng LAN.

3.4.2.Trình tự sử lý một giao dịch trong cụm Galera

Client thực hiện một giao dịch đến một nút trong cụm (Hình 3.9).

Hình 3.10. Client gửi giao dịch đến một nút

Hình 3.10 mô tả nút sau khi được cập nhập đã gửi thông điệp chứa sự thay đổi đi tất cả các nút khác trong cụm.

34

Hình 3.11. Thông điệp được gửi đến các nút khác

Cụm thực hiện việc đồng bộ ảo (Hình 3.11). Các nút xác nhận đã nhận thông điệp và trả lời client.

Hình 3.12. Các nút thực hiện đồng bộ ảo