Posted inMySQL

MySQL Replication Filters: Tuyệt chiêu lọc Database và Table để ‘giải cứu’ Slave

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

Câu chuyện thực tế: Khi ‘copy-paste’ toàn bộ dữ liệu là thảm họa

Cách đây không lâu, mình nhận task thiết lập một server Replica cho đội Data Analyst. Hệ thống Master lúc đó đang gánh gần 1TB dữ liệu từ 50 microservices khác nhau.

Sai lầm lớn nhất của mình là giữ nguyên cấu hình mặc định: Master có gì, Slave có nấy. Chỉ sau 2 tuần, ổ cứng Slave báo đỏ (95% disk usage) vì chứa hàng tá dữ liệu rác mà đội Analyst không bao giờ dùng tới. Tệ hơn, việc đồng bộ các bảng log khổng lồ khiến Seconds_Behind_Master vọt lên con số 3600 giây. Slave liên tục bị treo do nghẽn I/O.

Đỉnh điểm là một đêm nọ, mình phải dậy lúc 3 giờ sáng để dọn dẹp database vì Slave bị ‘đứng hình’. Bài học rút ra rất rõ ràng: Trong môi trường production, đồng bộ 100% dữ liệu đôi khi là một sự lãng phí tài nguyên trầm trọng. Chúng ta cần MySQL Replication Filters.

Tại sao bạn không nên đồng bộ mọi thứ?

Việc lọc dữ liệu đồng bộ mang lại 3 lợi ích sát sườn:

  • Tiết kiệm chi phí: Slave chỉ giữ lại dữ liệu cần thiết. Bạn có thể giảm dung lượng ổ cứng từ 1TB xuống còn 200GB, tiết kiệm đáng kể chi phí Cloud.
  • Bảo mật: Ngăn chặn các thông tin nhạy cảm như user_passwords hoặc credit_cards xuất hiện trên các server dùng cho báo cáo.
  • Tăng tốc độ query: Giảm tải I/O giúp Slave xử lý các câu lệnh SQL nhanh hơn, giảm độ trễ đồng bộ xuống mức gần bằng 0.

Hai hướng tiếp cận: Lọc ở Master hay lọc ở Slave?

Bạn có hai lựa chọn, nhưng hãy cẩn thận vì mỗi cách đều có ‘cạm bẫy’ riêng.

1. Lọc tại Master (Binary Log Filters)

Master sẽ chỉ ghi vào Binlog những thay đổi của các database được chỉ định thông qua binlog-do-db hoặc binlog-ignore-db.

# Cấu hình tại Master (my.cnf)
[mysqld]
binlog-do-db=db_important

Cảnh báo: Mình khuyên bạn không nên dùng cách này. MySQL lọc dựa trên database đang được USE. Nếu bạn đang USE db_other nhưng lại UPDATE db_important.table, thay đổi đó sẽ bị bỏ qua. Kết quả là Slave bị mất dữ liệu mà bạn không hề hay biết.

2. Lọc tại Slave (Replication Filters) – Cách an toàn nhất

Master cứ gửi hết log đi, Slave sẽ tự chọn lọc cái nào cần thực thi. Cách này an toàn hơn vì nó không làm mất dữ liệu gốc ở Master.

Các tham số bạn cần nhớ:

  • replicate-do-db: Chỉ lấy database này.
  • replicate-wild-do-table: Đồng bộ theo pattern (ví dụ: sales_%). Đây là lựa chọn tối ưu nhất.

Cấu hình chuẩn cho môi trường Production

Dựa trên kinh nghiệm vận hành, mình luôn ưu tiên dùng wildcard filtering để tránh các lỗi liên quan đến ngữ cảnh database.

Bước 1: Chỉnh sửa file cấu hình Slave

Mở file /etc/mysql/my.cnf trên Slave và thêm cấu hình sau:

[mysqld]
# Chỉ đồng bộ database ecommerce
replicate-wild-do-table=ecommerce.%

# Chỉ đồng bộ các bảng báo cáo trong database analytics
replicate-wild-do-table=analytics.report_%

# Loại bỏ các bảng log tạm
replicate-wild-ignore-table=ecommerce.temp_logs

Bước 2: Áp dụng thay đổi

Bạn có thể restart MySQL để nhận cấu hình. Tuy nhiên, nếu muốn tránh downtime, hãy thực hiện trực tiếp trong MySQL shell:

STOP SLAVE SQL_THREAD;
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('ecommerce.%', 'analytics.report_%');
START SLAVE SQL_THREAD;

Bước 3: Kiểm tra lại

Chạy lệnh SHOW SLAVE STATUS\G. Hãy kiểm tra kỹ dòng Replicate_Wild_Do_Table để đảm bảo các filter đã hoạt động đúng như mong đợi.

Lưu ý ‘xương máu’ để không làm hỏng hệ thống

  1. Ưu tiên Wildcard: Luôn dùng replicate-wild-do-table thay vì replicate-do-db. Nó giúp bạn tránh được lỗi ‘cross-database updates’ cực kỳ khó chịu.
  2. Quản lý Relay Log: Dù Slave lọc bỏ dữ liệu, Master vẫn gửi toàn bộ file log sang. Hãy cấu hình relay_log_purge = 1. Slave sẽ tự động xóa log sau khi xử lý xong, tránh việc đầy ổ cứng do file tạm.
  3. Giám sát định kỳ: Sử dụng pt-table-checksum để kiểm tra độ lệch dữ liệu giữa Master và Slave. Đừng chủ quan, đôi khi filter của bạn có thể bỏ sót một vài bảng quan trọng do sai sót trong lúc gõ pattern.

Làm chủ kỹ thuật lọc này không chỉ giúp hệ thống chạy mượt mà hơn. Nó còn giúp bạn chứng tỏ năng lực tối ưu hệ thống trong mắt đồng nghiệp. Nếu Slave của bạn đang ‘thở dốc’ vì quá tải dữ liệu, hãy thử áp dụng ngay hôm nay!

Share:
Tags: