Cách MySQL replication full xử lý lỗi máy slave

Khi chạy replication full (master–slave) mà máy slave (bản sao) bị lỗi (treo, mất kết nối, crash, hoặc restart) thì MySQL có cơ chế giúp slave tự động đồng bộ liên tục và "bắt kịp" master khi quay lại.

Cách MySQL replication full xử lý lỗi máy slave

1. Slave lưu lại vị trí binlog (log file + position) cuối cùng đã áp dụng
   • Slave ghi lại checkpoint trong table mysql.slave_master_info hoặc trong file (tuỳ config).
   • Khi slave bị tạm ngưng, nó biết mình đã apply đến đâu.
2. Khi slave kết nối lại với master
   • Slave gửi yêu cầu BINLOG_DUMP bắt đầu từ vị trí đã lưu.
   • Master gửi tiếp các sự kiện binlog kể từ vị trí đó.
   • Slave áp dụng các event này để "bắt kịp" lại.
3. Nếu slave bị lỗi lâu, master vẫn giữ binlog đủ lâu để slave lấy lại dữ liệu
   • Cần config expire_logs_days hoặc binlog_expire_logs_seconds sao cho đủ lớn, tránh bị xoá binlog quá sớm.
   • Nếu binlog cũ bị xoá trước khi slave kịp lấy, slave sẽ không thể đồng bộ và cần resync toàn bộ (ví dụ dump lại DB master sang slave).
4. Nếu slave bị mất dữ liệu hoặc crash nặng
   • Phải làm resync full:
     • Tạo bản dump mới từ master (ví dụ mysqldump) hoặc snapshot.
     • Restore lên slave.
     • Slave bắt đầu replication lại từ đầu (hoặc vị trí mới).

Tóm lại:

Lời khuyên vận hành

• Luôn monitor replication lag (thời gian trễ giữa master và slave).
• Tăng expire_logs_days đủ lâu để slave không bị mất dữ liệu binlog.
• Backup định kỳ, chuẩn bị kịch bản resync full.
• Có thể dùng GTID-based replication để quản lý checkpoint dễ hơn và chính xác hơn.