Posted inMySQL

Xử lý lệch dữ liệu MySQL Replication: Tuyệt chiêu dùng Percona Toolkit không cần Downtime

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

Khi Replication báo “xanh” nhưng dữ liệu lại “sai”

2 giờ sáng, Slack nổ thông báo liên tục. Hệ thống monitoring báo Data Drift: Dữ liệu báo cáo trên Slave khác hẳn Master, dù Seconds_Behind_Master vẫn bằng 0. Đây là tình huống cực kỳ oái oăm. Replication vẫn chạy, nhưng nội dung bên trong mỗi ông một phách.

Dân làm Ops chắc chẳng lạ gì cảnh này. Có thể ai đó đã lỡ tay ghi đè dữ liệu trực tiếp lên Slave. Hoặc đôi khi một bug hiếm gặp khiến transaction không được replicate đồng nhất. Câu hỏi đặt ra: Làm sao biết chính xác table nào lệch mà không phải dump/restore hàng trăm GB dữ liệu?

Vì sao các cách truyền thống thường thất bại?

Thông thường, khi phát hiện lệch dữ liệu, chúng ta hay nghĩ đến hai phương án:

  • Dùng mysqldump: Dump từ Master rồi restore sang Slave. Với DB tầm 500GB, việc lock bảng để dump và truyền tải qua network là một thảm họa. Hệ thống của bạn có thể phải ngừng hoạt động (downtime) cả tiếng đồng hồ.
  • So sánh COUNT(*): Cách này chỉ đếm dòng. Nó hoàn toàn bất lực nếu số dòng bằng nhau nhưng nội dung bên trong (như giá tiền, trạng thái đơn hàng) bị sai lệch.

Lúc này, Percona Toolkit với bộ đôi pt-table-checksum và pt-table-sync là cứu cánh thực sự. Nó giúp xử lý data drift mà vẫn giữ hệ thống online 24/7.

Cơ chế thông minh của Percona Toolkit

pt-table-checksum không kéo dữ liệu về máy local để so sánh. Thay vào đó, nó chia nhỏ bảng thành các chunk (đoạn) và chạy lệnh SQL ngay trên Master để tính toán checksum. Nhờ cơ chế replication, các lệnh này tự động thực thi trên Slave. Cuối cùng, tool chỉ cần so sánh kết quả checksum giữa hai bên để chỉ điểm bảng nào đang lỗi.

Cài đặt nhanh

Trên Ubuntu/Debian, bạn chỉ cần một lệnh:

sudo apt-get install percona-toolkit

Với CentOS/RHEL, hãy dùng yum:

sudo yum install percona-toolkit

Bước 1: Truy tìm bảng lệch với pt-table-checksum

Trước khi bắt đầu, hãy tạo một user percona_user có quyền SUPER và REPLICATION CLIENT. User này cần toàn quyền trên database percona để lưu kết quả tạm.

Chạy lệnh kiểm tra như sau:

pt-table-checksum h=master_ip,u=percona_user,p=password \
    --databases=my_production_db \
    --replicate=percona.checksums \
    --create-replicate-table \
    --no-check-replication-filters

Giải thích nhanh:

  • --replicate: Lưu kết quả vào bảng percona.checksums.
  • --create-replicate-table: Tự khởi tạo bảng nếu chưa có.
  • --no-check-replication-filters: Ép tool kiểm tra cả các bảng bị filter trong config MySQL.

Sau khi chạy, hãy nhìn vào cột DIFFS. Nếu con số này lớn hơn 0, bảng đó chắc chắn đã bị lệch dữ liệu.

Mẹo nhỏ: Với bảng trên 10 triệu row, mình luôn thêm --max-load Threads_running=25. Nếu server quá tải, tool sẽ tự tạm dừng để bảo vệ hệ thống.

Bước 2: Đồng bộ dữ liệu bằng pt-table-sync

Xác định được bảng lỗi (ví dụ: orders) rồi, giờ là lúc sửa sai. pt-table-sync sẽ tự sinh ra các lệnh REPLACE hoặc DELETE để đưa Slave về trạng thái giống Master.

Đừng vội thực thi ngay. Hãy chạy chế độ “dry run” để xem tool định sửa gì:

pt-table-sync --print \
    --replicate=percona.checksums \
    h=master_ip,u=percona_user,p=password \
    h=slave_ip

Nếu các câu lệnh SQL hiện ra trông ổn, hãy gõ lệnh thực thi:

pt-table-sync --execute \
    --replicate=percona.checksums \
    h=master_ip,u=percona_user,p=password \
    h=slave_ip

Lưu ý: Quá trình này sẽ ghi dữ liệu trực tiếp vào Slave. Nếu bảng quá lớn, hãy theo dõi sát sao I/O và load của server.

Vài “hố vôi” cần tránh khi chạy trên Production

Qua nhiều lần xử lý các database lớn, mình rút ra 4 lưu ý quan trọng:

  1. Bắt buộc có Primary Key: Tool hoạt động dựa trên Index. Nếu bảng không có PK, nó sẽ quét toàn bộ bảng (Full Table Scan), gây lag và khóa bảng rất nặng.
  2. Độ trễ Network: Dù chỉ gửi checksum, nhưng nếu Master và Slave ở hai Region khác nhau (ví dụ Singapore và Mỹ), quá trình này vẫn tốn thời gian.
  3. Cẩn thận với Triggers: Nếu Slave có trigger tự động cập nhật bảng khác, việc sync có thể gây ra hiệu ứng domino ngoài ý muốn.
  4. Quyền ghi: Hãy chắc chắn user thực hiện có quyền SUPER để bypass chế độ read_only = 1 trên Slave.

Lời kết

Lệch dữ liệu MySQL là chuyện sớm muộn cũng gặp khi vận hành lâu dài. Thay vì tốn cả ngày để dump/restore, làm chủ Percona Toolkit sẽ giúp bạn xử lý vấn đề gọn gàng và chuyên nghiệp. Lần tới nếu bị gọi dậy lúc nửa đêm, hãy cứ bình tĩnh gõ lệnh, dữ liệu của bạn sẽ sớm khớp trở lại thôi.

Share:
Tags: