Posted inMySQL

MySQL Multi-Source Replication: Tuyệt chiêu gom ‘trăm sông về một biển’ cho kỹ sư Data

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

Bắt tay vào làm: 5 phút để ‘nhập giang hồ’

Giả sử bạn đang quản lý 2 con Master (Source A và Source B) và cần đổ toàn bộ dữ liệu về một con Slave (Replica) duy nhất để làm báo cáo. Thay vì loay hoay với code, hãy tận dụng ngay từ khóa FOR CHANNEL. Đây chính là “chìa khóa” để MySQL phân biệt các luồng dữ liệu khác nhau.

Sau khi đã tạo user replication trên các Master, tại con Replica, bạn chỉ cần nạp cấu hình bằng vài dòng lệnh “ăn tiền” sau:

-- Cấu hình kênh từ Source A (Ví dụ: DB Orders)
CHANGE REPLICATION SOURCE TO 
    SOURCE_HOST='192.168.1.10', 
    SOURCE_USER='repl_user', 
    SOURCE_PASSWORD='password_siêu_cấp', 
    SOURCE_LOG_FILE='mysql-bin.000001', 
    SOURCE_LOG_POS=156
    FOR CHANNEL 'source_A';

-- Cấu hình kênh từ Source B (Ví dụ: DB Users)
CHANGE REPLICATION SOURCE TO 
    SOURCE_HOST='192.168.1.20', 
    SOURCE_USER='repl_user', 
    SOURCE_PASSWORD='password_siêu_cấp', 
    SOURCE_LOG_FILE='mysql-bin.000005', 
    SOURCE_LOG_POS=450
    FOR CHANNEL 'source_B';

-- Kích hoạt song song cả hai luồng
START REPLICA FOR CHANNEL 'source_A';
START REPLICA FOR CHANNEL 'source_B';

Để biết mọi thứ có đang trơn tru hay không, hãy chạy SHOW REPLICA STATUS\G. Nếu thấy cả hai channel đều báo Running: Yes thì chúc mừng, bạn đã xong phần khung!

Câu chuyện thực tế: Khi 5 Microservices cần ‘họp mặt’

Hồi mình còn làm ở một startup thương mại điện tử, hệ thống có 5 microservices chạy 5 DB riêng biệt. Một ngày đẹp trời, sếp yêu cầu làm Dashboard tổng hợp doanh thu theo thời gian thực trước 8 giờ sáng mai. Lúc đó, ý định viết code để join 5 cái DB từ xa khiến mình toát mồ hôi hột vì độ trễ và phức tạp.

Cứu tinh lúc ấy chính là MySQL Multi-Source Replication. Thay vì dùng các công cụ ETL cồng kềnh, mình đồng bộ thẳng 5 nguồn dữ liệu (tổng khoảng 200GB) về một con Replica trung tâm cấu hình 16GB RAM. Kết quả thật bất ngờ:

  • Báo cáo siêu tốc: Query thoải mái trên Replica mà không làm ảnh hưởng tới tốc độ đặt hàng của khách trên Master.
  • Backup nhàn tênh: Thay vì chạy 5 job backup, mình chỉ cần gom tất cả lại và backup một lần duy nhất.
  • Phân tích đa vùng: Gom data từ server Singapore và Mỹ về Việt Nam với độ trễ chỉ khoảng 100-200ms.

Cấu hình chi tiết: Đừng để ‘sai một ly đi một dặm’

Muốn hệ thống chạy ổn định ở môi trường production, mình khuyên thật lòng: Hãy dùng GTID (Global Transaction Identifiers). Đừng dùng kiểu binlog_file truyền thống nếu bạn không muốn thức đêm để fix lỗi mỗi khi Master gặp sự cố.

1. Tối ưu file my.cnf

Mở file cấu hình lên và đảm bảo các thông số sau đã hiện diện:

[mysqld]
server-id = 101 # Mỗi server một số, không được trùng
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = /var/log/mysql/mysql-bin.log
log_slave_updates = ON # Cần thiết nếu bạn muốn Replica này làm nguồn cho các node khác

2. Bảo mật User Replication

Tuyệt đối không dùng user root. Hãy tạo một user riêng với quyền hạn vừa đủ để giảm thiểu rủi ro bảo mật:

CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password_siêu_cấp';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

3. Mẹo dùng bộ lọc (Filters)

Thông thường, bạn chỉ cần lấy một vài DB quan trọng chứ không cần bê hết cả server về. Ví dụ: Source A chỉ lấy db_orders, còn Source B lấy db_users. Hãy cấu hình bộ lọc trực tiếp để tránh tình trạng dữ liệu bị chồng chéo:

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db_orders) FOR CHANNEL 'source_A';
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db_users) FOR CHANNEL 'source_B';

Những ‘cú lừa’ mình từng nếm trải

Nhìn cấu hình có vẻ mượt mà, nhưng khi dữ liệu thực tế bắt đầu đổ về ào ạt (tầm 10 triệu record mỗi ngày), bạn sẽ thấy những vấn đề cực kỳ nhức nhối.

Xung đột khóa chính (Primary Key Conflict)

Đây là lỗi kinh điển nhất. Nếu cả Source A và Source B cùng tạo ra User có ID 1, khi đổ về Replica, hệ thống sẽ báo lỗi Duplicate entry và dừng ngay lập tức.

Cách mình đã xử lý:

  • Chuyển toàn bộ Primary Key sang dạng UUID thay vì Auto Increment.
  • Nếu lỡ dùng Auto Increment, hãy cấu hình auto_increment_offset khác nhau (ví dụ: Source A số lẻ, Source B số chẵn).
  • Hoặc đơn giản nhất: Mỗi Source đổ vào một Schema (Database) riêng biệt trên con Replica.

Xử lý tình trạng Slave lag

Khi gánh dữ liệu từ nhiều nguồn, con Replica rất dễ bị đuối, dẫn đến việc dữ liệu trên Dashboard bị cũ. Mình đã tối ưu bằng cách bật multi-threaded slave (MTS) trên MySQL 8.0. Với server 16 cores, mình set 8 workers là vừa đẹp:

set global slave_parallel_type = 'LOGICAL_CLOCK';
set global slave_parallel_workers = 8;

Cấu hình này giúp giảm độ trễ từ 30 phút xuống chỉ còn dưới 1 giây. Cảm giác nhìn Dashboard nhảy số liên tục rất là “phê”!

Lời kết từ phòng máy

Sau nhiều năm vận hành, mình rút ra vài điều xương máu: Luôn giám sát relay logs để tránh đầy ổ cứng và hãy dùng Percona XtraBackup thay vì mysqldump thông thường. Nếu bạn đang có ý định xây dựng một kho dữ liệu tập trung, MySQL Multi-Source chắc chắn là công cụ đầu tiên bạn nên nghĩ tới. Có chỗ nào cấu hình mà chưa thấy chạy, cứ nhắn mình một tiếng ở phần bình luận nhé!

Share:
Tags: