Posted inMySQL

Delayed Replication trong MySQL: “Phao cứu sinh” khi lỡ tay xóa nhầm dữ liệu

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

Khi lệnh DELETE thiếu điều kiện WHERE: Backup thôi là chưa đủ

Bất kỳ DBA hay kỹ sư vận hành nào cũng từng trải qua cảm giác “tim ngừng đập” khi nhận thông báo: “Em lỡ chạy nhầm script xóa dữ liệu trên Production”. Nếu chỉ dựa vào bản backup định kỳ lúc 2h sáng, bạn sẽ đối mặt với thảm họa. Việc khôi phục database nặng vài trăm GB từ file dump, sau đó replay Binary Log để tìm lại dữ liệu lúc 3h chiều có thể ngốn cả ngày trời. Trong kinh doanh, mỗi giờ downtime là một con số thiệt hại khổng lồ.

Tôi từng xử lý một sự cố tại sàn TMĐT khi dev chạy nhầm script cleanup trên cụm DB 500GB. Quá trình restore mất hơn 6 tiếng, khiến website tê liệt hoàn toàn và gây thiệt hại ước tính hàng chục nghìn USD. Mô hình Master-Slave thông thường không thể cứu bạn vì lệnh xóa sẽ được replicate sang Slave chỉ trong vài mili giây. Đó là lúc bạn cần đến Delayed Replication.

Delayed Replication: “Cỗ máy thời gian” cho Database

Delayed Replication cho phép cấu hình một node Slave (Replica) luôn chạy chậm hơn Master một khoảng thời gian xác định, ví dụ 1 tiếng hoặc 3 tiếng.

Cơ chế này rất thông minh: Slave vẫn nhận Binary Log từ Master về Relay Log ngay lập tức nhưng chưa thực thi ngay. Nó sẽ đợi đủ thời gian cấu hình mới bắt đầu apply lệnh. Nếu ai đó lỡ tay DROP table lúc 10h sáng, và bạn để trễ 1 tiếng, bạn có đúng 60 phút để ngăn chặn lệnh đó thực thi trên Slave. Đây chính là khoảng thời gian vàng để cứu vãn hệ thống.

3 bước cấu hình Delayed Replication

Giả sử bạn đã có hệ thống Replication đang chạy. Việc biến một Slave thông thường thành Delayed Slave chỉ mất chưa đầy 1 phút. Dưới đây là cách thiết lập độ trễ 3600 giây (1 tiếng):

1. Tạm dừng tiến trình Replication

-- Dùng cho mọi phiên bản
STOP SLAVE;
-- Hoặc từ MySQL 8.0.22 trở đi:
STOP REPLICA;

2. Thiết lập độ trễ (Delay)

Sử dụng tham số MASTER_DELAY để chỉ định thời gian chờ. Đơn vị tính ở đây là giây.

-- MySQL bản cũ
CHANGE MASTER TO MASTER_DELAY = 3600;

-- MySQL 8.0.23 trở lên
CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600;

Kinh nghiệm của tôi là nên để từ 1 đến 3 tiếng. Khoảng thời gian này đủ để team vận hành kịp phát hiện sự cố nhưng không quá lâu khiến Relay Log phình quá to.

3. Khởi động lại Slave

START REPLICA;

Cách kiểm tra Slave có đang “đợi” hay không?

Để chắc chắn cấu hình đã ăn tiền, bạn hãy kiểm tra trạng thái Slave:

SHOW REPLICA STATUS\G

Hãy chú ý hai chỉ số này:

  • SQL_Delay: Hiển thị 3600 (độ trễ bạn đã cài).
  • SQL_Remaining_Delay: Số giây còn lại Slave phải chờ trước khi chạy event tiếp theo.

Khi quản lý hệ thống có bảng orders vượt mốc 50 triệu record, tôi nhận thấy Delayed Slave ngốn rất ít CPU. Tuy nhiên, bạn cần chú ý dung lượng ổ cứng vì nó phải lưu trữ lượng Relay Log chưa apply trong suốt 1 tiếng đó.

Kịch bản ứng cứu: 15 phút để hồi sinh dữ liệu

Giả sử lúc 10:00, lệnh DROP TABLE users; tai hại xuất hiện. Bạn phát hiện lúc 10:10. Vì Slave trễ 1 tiếng, dữ liệu trên đó vẫn còn nguyên đến tận 11:00.

Quy trình xử lý cấp tốc:

  1. Ngắt kết nối ngay: Chạy STOP REPLICA; trên Slave để chặn đứng lệnh DROP.
  2. Xác định điểm dừng: Tìm vị trí (Log position) ngay trước câu lệnh DROP trong Relay Log.
  3. Chạy nốt dữ liệu sạch: Sử dụng lệnh UNTIL để Slave apply log đến sát thời điểm lỗi: 
    START REPLICA UNTIL MASTER_LOG_FILE = 'binlog.000001', MASTER_LOG_POS = 1024;
  4. Khôi phục: Export table từ Slave và import ngược lại Master. Hệ thống sẽ trở lại trạng thái bình thường chỉ trong tích tắc.

Lưu ý quan trọng để tránh “gậy ông đập lưng ông”

Dù cực kỳ hữu ích, Delayed Replication không phải là viên đạn bạc cho mọi vấn đề.

  • Tuyệt đối không dùng làm Read Replica: Đừng để ứng dụng đọc dữ liệu từ node này, trừ khi bạn muốn khách hàng nhìn thấy số dư tài khoản của… 1 tiếng trước.
  • Giám sát ổ cứng: File Relay Log có thể chiếm hàng chục GB nếu hệ thống có mật độ ghi cao. Hãy đảm bảo relay_log_purge = 1 để MySQL tự dọn dẹp sau khi apply.
  • Vẫn phải Backup: Delayed Replication không bảo vệ bạn trước ransomware hoặc hỏng hóc vật lý trên cả cụm server.

Thiết lập Delayed Replication giống như mua bảo hiểm thân vỏ cho xe hơi. Hy vọng bạn không bao giờ phải dùng đến, nhưng khi có sự cố, nó chính là thứ giữ lại sự nghiệp của bạn.

Share:
Tags: