Vì sao mô hình Replication truyền thống không còn đủ an toàn?
Vận hành MySQL Master-Slave kinh điển luôn đi kèm một nỗi lo thường trực: Master sập bất ngờ lúc nửa đêm. Khi đó, việc xử lý thủ công đặt ra nhiều bài toán hóc búa:
- Replica nào đang giữ binary log mới nhất?
- Promote replica lên Master có làm mất mát dữ liệu đang bay (in-flight transaction) không?
- Xử lý xung đột ra sao nếu xảy ra split-brain và hai node cùng nhận ghi?
Trong thực tế, rủi ro mất dữ liệu tỷ lệ thuận với quy mô hệ thống. Một hệ sinh thái thanh toán xử lý 2.000 write OPS chỉ cần trễ vài giây replication lag là RPO (Recovery Point Objective) đã lệch hàng nghìn bản ghi. Thao tác failover thủ công thường ngốn từ 10 đến 30 phút downtime. Con số đó vượt xa mức cam kết SLA tiêu chuẩn.
Hệ thống hiện đại cần cơ chế tự đồng thuận (consensus), tự loại bỏ node chết và bầu leader mới theo thời gian thực. MySQL Group Replication (MGR) được Oracle thiết kế chính xác để giải quyết bài toán này.
Cơ chế hoạt động của Paxos và Group Replication
Khác với cơ chế Asynchronous sao chép một chiều thụ động, MGR tích hợp tầng truyền thông nhóm XCom (Group Communication System), vận hành dựa trên biến thể của thuật toán đồng thuận Paxos.
1. Luồng xử lý giao dịch qua Paxos
Khi transaction chuẩn bị commit trên một node, tiến trình ghi đĩa chưa diễn ra ngay. Thay vào đó, dữ liệu write-set (chứa hash khóa chính và snapshot version) được broadcast tới toàn bộ thành viên trong cụm qua port XCom (mặc định 33061).
Cụm tiến hành biểu quyết theo cơ chế đa số (Quorum):
- Chỉ cần trên 50% số node xác nhận và thống nhất thứ tự thực thi (global order), transaction sẽ được coi là hợp lệ.
- Giai đoạn Certification sẽ kiểm tra xung đột phiên bản. Nếu không có transaction nào ghi đè cùng dòng trước đó, lệnh commit trên node gốc hoàn tất và các node còn lại áp dụng thay đổi.
- Cụm cần tối thiểu
2F + 1node để chịu lỗiFnode rớt đồng thời. Với mô hình 3 node (N=3), cụm vẫn hoạt động ổn định khi 1 node gặp sự cố.
2. Single-Primary vs Multi-Primary Mode
MGR hỗ trợ hai chế độ triển khai:
- Single-Primary Mode (Khuyên dùng): Cụm chỉ định duy nhất một node nhận cả Read/Write, các node còn lại đóng vai trò Read-Only (Secondary). Khi Primary sập, Paxos tự động bầu Secondary có trọng số cao nhất lên thay thế trong vòng 2-5 giây. Ứng dụng hầu như không cần can thiệp logic.
- Multi-Primary Mode: Toàn bộ node đều có thể nhận ghi cùng lúc. Khi hai node đồng thời cập nhật một row, cơ chế Certification sẽ tự động reject và rollback transaction đến sau. Chế độ này kén use-case và đòi hỏi ứng dụng phải xử lý retry chặt chẽ.
Triển khai cụm MySQL Group Replication 3 Node
Mô hình triển khai gồm 3 node chạy Ubuntu 22.04 LTS và MySQL 8.0 theo kiến trúc Single-Primary:
- Node 1:
192.168.10.11(hostname:mgr-node1) - Node 2:
192.168.10.12(hostname:mgr-node2) - Node 3:
192.168.10.13(hostname:mgr-node3)
Bước 1: Cấu hình điều kiện tiên quyết
MGR yêu cầu cấu hình bắt buộc: dùng storage engine InnoDB, bật GTID (Global Transaction Identifier), định dạng binary log dạng ROW và mọi table phải có Primary Key.
Mở file /etc/mysql/mysql.conf.d/mysqld.cnf trên Node 1 và bổ sung:
[mysqld]
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW
log_replica_updates = ON
binlog_checksum = NONE
# Khởi chạy plugin Group Replication
plugin_load_add = 'group_replication.so'
group_replication_group_name = "8a9f24e0-7bf2-11ed-a1eb-0242ac120002"
group_replication_start_on_boot = OFF
group_replication_local_address = "192.168.10.11:33061"
group_replication_group_seeds = "192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061"
group_replication_bootstrap_group = OFF
group_replication_single_primary_mode = ON
group_replication_enforce_update_everywhere_checks = OFFTrên Node 2 và Node 3, dùng cấu hình tương tự nhưng thay đổi server_id thành 2 và 3, đồng thời trỏ đúng IP máy đó tại tham số group_replication_local_address.
Bước 2: Tạo user replication chuyên dụng
Đăng nhập vào MySQL trên cả 3 node để cấp quyền cho kênh hồi phục dữ liệu:
SET SQL_LOG_BIN=0;
CREATE USER 'repl'@'%' IDENTIFIED BY 'MatKhauBaoMatCucCao123@';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='MatKhauBaoMatCucCao123@' FOR CHANNEL 'group_replication_recovery';Bước 3: Khởi tạo nhóm (Bootstrap từ Node 1)
Chỉ một node duy nhất được phép kích hoạt cờ bootstrap để khởi sinh cụm. Thực thi trên Node 1:
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;Hãy tắt ngay cờ bootstrap_group về OFF. Thao tác này ngăn node tự tạo nhóm mới khi khởi động lại dịch vụ.
Bước 4: Nối Node 2 và Node 3 vào cụm
Trên Node 2 và Node 3, chạy lệnh tham gia trực tiếp mà không dùng cờ bootstrap:
START GROUP_REPLICATION;Hệ thống tự động đồng bộ schema và dữ liệu hiện có từ Node 1 sang các node mới qua recovery channel.
Bước 5: Xác nhận trạng thái vận hành
Truy vấn bảng Performance Schema trên bất kỳ node nào:
SELECT member_id, member_host, member_port, member_state, member_role
FROM performance_schema.replication_group_members;Khi các node đều hiển thị trạng thái ONLINE, cụm đã sẵn sàng phục vụ:
+--------------------------------------+---------------+-------------+--------------+-------------+
| MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+--------------------------------------+---------------+-------------+--------------+-------------+
| 306c58cf-5e8c-11ed-9f86-000c29a8a111 | 192.168.10.11 | 3306 | ONLINE | PRIMARY |
| 422d8612-5e8c-11ed-8f52-000c29a8a222 | 192.168.10.12 | 3306 | ONLINE | SECONDARY |
| 505d9123-5e8c-11ed-7a11-000c29a8a333 | 192.168.10.13 | 3306 | ONLINE | SECONDARY |
+--------------------------------------+---------------+-------------+--------------+-------------+Bước 6: Giả lập sự cố và kiểm tra cơ chế Failover
Tắt tiến trình MySQL trên Node 1 để kiểm tra phản ứng của hệ thống:
sudo systemctl stop mysqlKiểm tra lại trạng thái cụm từ Node 2. Trong vòng 3 đến 5 giây, Node 1 chuyển sang trạng thái UNREACHABLE rồi tự động bị loại khỏi danh sách.
Node 2 hoặc Node 3 sẽ được nâng cấp làm PRIMARY mới. Toàn bộ transaction đã commit đều được bảo toàn nguyên vẹn (RPO = 0).
Tổng kết và khuyến nghị sản xuất
MySQL Group Replication cung cấp kiến trúc cơ sở dữ liệu phân tán chuẩn mực, ngăn chặn nguy cơ split-brain mà không cần phần mềm bên thứ ba can thiệp vào tầng consensus. Để đưa vào môi trường Production an toàn, hãy lưu ý:
- Luôn duy trì số lượng node lẻ (tối thiểu 3 node) để đảm bảo điều kiện tính Quorum.
- Đặt ProxySQL hoặc MySQL Router ở tầng giữa để điều phối read/write query tự động tới đúng Primary node mới sau failover.
- Giữ độ trễ mạng giữa các node dưới 10ms để giảm thiểu overhead của bước Paxos consensus.
