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 Các nút thực hiện cập nhập cở dữ liệu (Hình 3.12).
35 - Chi tiết:
Sau đây là biểu đồ tuần tự thể hiện trình tự đồng bộ cơ sở dữ liệu từ khi client thực hiện những thay đổi trên một nút.
Hình 3.14. Biểu đồ tuần tự quá trình thực hiện đồng bộ
Client thực hiện giao dịch trên một nút. Khi client phát đi lệnh COMMIT, nhưng thực tế trước khi master server COMMIT lại thì tất cả những gì thay đổi trên cơ sở dữ liệu (giao dịch), 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 đó…sẽ được ghi vào write-set.
Sau đó cơ sở dữ liệu sẽ gửi write-set tới tất cả các nút. Sau khi write-set được gửi đến tất cả các nút, các nút kiểm tra ID giao dịch so với ID giao dịch đã được thực hiện cuối cùng. Nếu không có xung đột gì thì giao dịch sẽ được thực hiện trên các nút. Việc kiểm tra và chấp nhận sẽ được thực hiện trên cả nút gửi write-set.
Nếu write-set không được chấp nhận thì nó sẽ bị xóa bỏ và được yêu cầu cung cấp lại. Cơ dữ liệu trên các nút được phục hồi về trạng thái trước đó.
Trong cụm cơ sở dữ liệu tất cả các nút đều giống nhau. Các nút đồng bộ với nhau bằng cách phục hồi và áp dụng những thay đổi về trạng thái theo trình tự giao dịch nối tiếp nhau.
Quản lý dòng chảy nhân bản đồng bộ
Cụm Galera đồng bộ những giao dịch nhưng việc áp dụng những giao dịch này lại không đồng bộ kể từ khi giao dịch được thực hiện trên nút nguồn. Để ngăn chặn một nút bất kì có trạng thái bị bỏ lại quá xa so với các nút khác. Galera thực hiện một cơ chế gọi là Flow Control.
36
Khi các write-set được gửi đến các nút, nếu chưa được thực hiện ngay nó sẽ được đưa vào hàng đợi. Khi hàng đợi quá nhiều, cơ chế Flow Control sẽ được áp dụng. Các nút sẽ tạm ngừng việc đồng bộ và hàng đợi sẽ được xử lý đến khi nào hàng đợi giảm tới một mức hợp lý thì cụm sẽ tiếp tục nhân bản.
3.5.Cài đặt và kiểm thử hệ thống 3.5.1.Cài đặt và cấu hình hệ thống 3.5.1.Cài đặt và cấu hình hệ thống
Ở đây thí nghiệm được tiến hành cài đặt trên 3 nút lần lượt ip như sau: Node1: 192.168.248.129/24
Node2: 192.168.248.131/24 Node3: 192.168.248.130/24
Thực hiện cài đặt MySQL galera trên node1, node2, node3 như sau: Cài đặt một số phụ trợ:
# apt-get install libaio1 libdbi-perl libdbd-mysql-perl mysql-client rsync Cài đặt MySQL server with wsrep patch:
32 bits:
# wget https://launchpad.net/codership-mysql/5.5/5.5.28-23.7/+download/mysql-server- wsrep-5.5.28-23.7-i386.deb && dpkg -i mysql-server-wsrep-5.5.28-23.7-i386.deb 64 bits:
# wget https://launchpad.net/codership-mysql/5.5/5.5.28-23.7/+download/mysql-server- wsrep-5.5.28-23.7-amd64.deb && dpkg -i mysql-server-wsrep-5.5.28-23.7-amd64.deb – Tải và cài đặt Galera:
32 bits:
# wget https://launchpad.net/galera/2.x/23.2.2/+download/galera-23.2.2-i386.deb && dpkg -i galera-23.2.2-i386.deb
64 bits:
# wget https://launchpad.net/galera/2.x/23.2.2/+download/galera-23.2.2-amd64.deb && dpkg -i galera-23.2.2-amd64.deb
– Cấu hình MySQL ban đầu cho các node: # /etc/init.d/mysql start
# mysql -u root
mysql> DELETE FROM mysql.user WHERE user='';
mysql> GRANT ALL ON *.* TO root@'%' IDENTIFIED BY 'P@ssw0rd';
mysql> UPDATE mysql.user SET Password=PASSWORD('P@ssw0rd') WHERE User='root';
mysql> GRANT ALL ON *.* to sst@'%' IDENTIFIED BY 'sstpasswd'; – Cấu hình MySQL để khởi động cùng hệ điều hành cho các node:
37
Cấu hình node1
# vi /etc/mysql/conf.d/wsrep.cnf
# Full path to wsrep provider library or 'none' wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Group communication system handle wsrep_cluster_address="gcomm://"
# State Snapshot Transfer method wsrep_sst_method=rsync
# SST authentication string. This will be used to send SST to joining núts. # Depends on SST method. For mysqldump method it is root:
wsrep_sst_auth=sst:sstpasswd # /etc/init.d/mysql restart
– Đối với nút đầu tiên “gcomm://” sẽ để trống để dễ dàng tạo các nút mới sau đó chúng ta sẽ kết nối lại với nút node3
Cấu hình MySQL trên node2 # vi /etc/mysql/conf.d/wsrep.cnf
# Full path to wsrep provider library or 'none' wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Group communication system handle
wsrep_cluster_address="gcomm://192.168.248.130,192.168.248.129"
# State Snapshot Transfer method wsrep_sst_method=rsync
# SST authentication string. This will be used to send SST to joining núts. # Depends on SST method. For mysqldump method it is root:
wsrep_sst_auth=sst:sstpasswd # /etc/init.d/mysql restart Cấu hình MySQL trên node3
# vi /etc/mysql/conf.d/wsrep.cnf