Bài 6: MySQL Replication với GTID: topology, semi-sync và giới hạn
Hiểu GTID, snapshot, topology một writer và semi-sync trước khi cấu hình replication. Đọc lag, fencing và giới hạn auto-increment offset.
Hai máy đều bật replication không tự trở thành một hệ HA có failover an toàn. Một node có dữ liệu trễ, một lần ghi ngoài ý muốn hoặc chuyển vai trò khi source cũ chưa bị cô lập đều có thể làm hai phía phân kỳ.
Bài dùng MySQL 8.4, GTID và InnoDB. Topology cơ sở là một source ghi, một replica dự phòng; dual-source vòng chỉ được phân tích như phương án có điều kiện. Không dùng các lệnh thiết lập replication để ghép hai database đang có dữ liệu khác nhau.
GTID định danh giao dịch, không thay snapshot
GTID gồm nguồn định danh và số giao dịch, giúp auto-position xác định phần log còn thiếu. MySQL vẫn có replication dùng file/position; GTID không phải bắt buộc cho mọi topology MySQL 8.4, nhưng là điều kiện của thiết kế trong bài.
Replica cần dữ liệu ban đầu nhất quán và GTID provenance đúng. Bật SOURCE_AUTO_POSITION không tự kiểm tra hai bảng nghiệp vụ đã giống nhau, cũng không tái tạo binlog đã purge. Lập kế hoạch snapshot/clone, retention và TLS trước khi cấu hình channel.
Một đường ghi dễ kiểm soát hơn hai đường
Để dự phòng, route ghi tới source được chọn và khóa ghi ứng dụng ở replica theo policy. Khi chuyển vai trò phải xác minh tiến độ replication, cô lập writer cũ và quản lý endpoint. read_only không ngăn mọi tài khoản có quyền cao; super_read_only có thêm tác dụng nhưng cũng cần đúng quy trình quản trị.
Topology vòng có thể được thiết kế, nhưng bản thân nó không giải quyết conflict, election hoặc fencing. Không khuyến nghị biến một cặp async thành active-active chỉ vì ứng dụng muốn ghi ở cả hai nơi. Nếu cần HA tự động, xem bộ InnoDB Cluster với các ràng buộc riêng.
Source/replica cần snapshot ban đầu đúng nguồn. GTID không tự đồng bộ hai database khác nhau. Timeout semi-sync có thể fallback async theo cấu hình.
Cuộn ngang hoặc chạm sơ đồ để mở bản đầy đủ. Hình được biên tập, không phải ảnh chụp kiểm thử.
Offset chỉ xử lý một loại va chạm
Trong ví dụ vòng hai node, increment 2 với offset 1/2 tạo dãy lẻ/chẵn cho AUTO_INCREMENT phù hợp. Nó không bảo vệ unique key khác, ID do ứng dụng cấp, UPDATE cùng dòng hoặc bất biến nghiệp vụ. Vì vậy không gọi offset là cách “triệt tiêu xung đột”.
Ví dụ 1,3,5 và 2,4,6 chỉ cho thấy hai tập số khác nhau, không chứng minh hệ thống nhất quán. Khi schema thay đổi, kiểm tra index, foreign key, transaction và quyền ghi trực tiếp trước khi đưa thêm writer vào thiết kế.
Chuẩn bị source và replica mới
Mỗi instance cần server_id/UUID khác nhau, GTID và binary logging phù hợp, dữ liệu ban đầu đúng nguồn. Không copy datadir của server rồi giữ nguyên auto.cnf như cách tạo máy mới. Bật GTID trên hệ đang chạy có quy trình chuyển đổi riêng.
[mysqld]
server_id = 21
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = mysql-bin
log_replica_updates = ON
Đây là phần cấu hình lab, không phải file đầy đủ hoặc migration trực tiếp. Replica dùng server_id khác. Restart gây gián đoạn, còn binlog retention phải đủ cho thời gian replica offline và nhu cầu PITR; không chọn bảy ngày chỉ vì ví dụ.
Tạo account đúng peer và yêu cầu TLS
CREATE USER 'repl_lab'@'192.168.10.22'
IDENTIFIED BY '<BI-MAT-RIENG>' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl_lab'@'192.168.10.22';
Quyền REPLICATION SLAVE vẫn là tên privilege ở đây, dù lệnh quản lý channel dùng SOURCE/REPLICA. Thay placeholder trong kênh quản trị an toàn và không đưa password vào script công khai. Hạn chế host, mạng và quyền đọc log theo thiết kế.
Các điểm kiểm chứng theo chủ đề; không phải mọi kết quả đều dẫn tới một nguyên nhân duy nhất.
Cuộn ngang hoặc chạm sơ đồ để mở bản đầy đủ. Hình được biên tập, không phải ảnh chụp kiểm thử.
Thiết lập một channel có provenance rõ
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='mysql-source.internal', SOURCE_PORT=3306,
SOURCE_USER='repl_lab', SOURCE_PASSWORD='<BI-MAT-RIENG>',
SOURCE_AUTO_POSITION=1, SOURCE_SSL=1,
SOURCE_SSL_CA='/path/to/ca.pem', SOURCE_SSL_VERIFY_SERVER_CERT=1;
START REPLICA;
SHOW REPLICA STATUS\G
Mẫu chạy trên replica lab mới đã provision đúng snapshot/GTID, hostname phải khớp chứng chỉ. Nó thay cấu hình channel mặc định; không chạy đè channel production. Không khép vòng ngược lại trước khi có phương án writer, conflict, fencing và recovery đầy đủ.
Semi-sync ACK không đồng nghĩa đã apply
Semi-sync chờ xác nhận từ replica theo cơ chế/plugin và wait point đã chọn; xác nhận nhận log không chứng minh giao dịch đã được apply hoặc SELECT trên replica đã thấy dữ liệu. Timeout có thể khiến source chuyển sang async theo cấu hình. Theo dõi trạng thái vận hành, không chỉ biến enabled.
Plugin, số ACK cần thiết, timeout và khả năng failover phải được kiểm thử với bản cụ thể. Không hứa zero data loss chỉ vì cài hai plugin. Replication giữa hai site có RTT cao còn làm tăng commit latency; chọn trade-off theo yêu cầu nghiệp vụ.
Nghiệm thu IO, apply và dữ liệu
SHOW REPLICA STATUS cần được đọc cùng Last_IO_Error, Last_SQL_Error, GTID nhận/thực thi và trạng thái worker. Hai thread báo Yes không chứng minh replica đã bắt kịp. Seconds_Behind_Source có giới hạn, không phải thước đo duy nhất hoặc bảo đảm bằng 0 là dữ liệu hoàn toàn mới.
Parallel workers có thể tăng khả năng apply khi workload có tính song song; không xóa mọi lag và không nên sao chép biến replica_parallel_type cũ vào 8.4. Đo queue, I/O, lock và transaction size trước thay. Checklist: snapshot đúng, TLS, GTID liên tục, writer duy nhất, cảnh báo timeout/lag, diễn tập chuyển vai trò và rollback.
Hai thread Yes nhưng replica vẫn chưa sẵn sàng tiếp quản
Tình huống giả định để luyện phân tích, không phải kết quả đo.
Giả sử IO và SQL thread đều Yes, nhưng một transaction lớn đang apply. Ứng dụng đọc replica chưa thấy đơn hàng mới, Seconds_Behind_Source chỉ là một trong các dữ kiện. Thu GTID nhận/thực thi, worker state, queue và thời gian cùng transaction mẫu để hiểu khoảng cách.
Nếu source đang có giao dịch mới liên tục, hai lần chụp tập GTID khác thời điểm không phải bằng chứng mất dữ liệu. Dùng mốc kiểm tra có kiểm soát trong lab hoặc quy trình consistency phù hợp. Không tắt replication rồi sửa dữ liệu tay để làm số liệu bắt kịp.
Trước promotion, cô lập đường ghi cũ bằng cơ chế đã kiểm chứng, xác nhận tập dữ liệu được chọn và chấp nhận RPO theo bằng chứng. Trường hợp source không còn tiếp cận được có thể không biết các commit cuối cùng, dù replica đã ACK một phần log. Nêu phần không chắc chắn trong báo cáo.
Đưa source cũ quay lại cần kiểm tra phân kỳ và topology, không đơn giản đổi read_only rồi cho ghi. Những lỗi này là lý do việc có hai bản sao khác với việc có một cơ chế election/fencing hoàn chỉnh. Diễn tập nên gồm cả phục hồi writer cũ, không chỉ khoảnh khắc ứng dụng kết nối được writer mới.
Nguồn đối chiếu và bài đọc tiếp
Phạm vi tham chiếu là tài liệu theo phiên bản ghi trong bài. Khi áp dụng, đối chiếu model triển khai, bản patch và quyền đang dùng; các ví dụ chưa được kiểm thử trên máy chủ thật.
