Database Replication: Hệ thống production giữ tốc độ và uptime khi DB chết như thế nào

TL;DR

Database replication = sao chép dữ liệu từ một Primary server sang một hoặc nhiều Replica. Primary xử lý writes. Replica hấp thụ read traffic và đứng sẵn để failover. Kết quả: hệ thống vừa nhanh hơn, vừa sẵn sàng cao hơn - mà không cần thay đổi application logic.

Tại sao một DB đơn lẻ không đủ

Khi traffic tăng, một database duy nhất trở thành điểm nghẽn và điểm chết duy nhất. Replication giải quyết năm vấn đề cùng lúc:

• Read scaling: Replica hấp thụ SELECT queries, giảm tải primary.
• High availability: Khi primary fail, promote replica lên làm primary mới trong vài giây.
• Disaster recovery: Cross-region replica bảo vệ khi toàn bộ data center gặp sự cố.
• Maintenance window: Chạy schema migration hay upgrade trên primary mà read traffic vẫn phục vụ từ replica.
• Analytics offload: Chạy query nặng, báo cáo, ETL trên replica - không ảnh hưởng production.

Primary và Replica làm gì

Primary là nguồn sự thật duy nhất. Nó nhận toàn bộ INSERT, UPDATE, DELETE; stream change log xuống các Replica liên tục.

Replica là bản sao read-only. Nó replay change log, phục vụ SELECT queries, và có thể được promote lên làm primary mới khi cần.

Topology phổ biến nhất trong production: 1 primary + N replicas. N thường từ 2 đến 4 tùy quy mô. Một số hệ thống lớn hơn dùng kiến trúc cascading replica - replica kết nối tới một replica khác thay vì trực tiếp tới primary, giúp giảm tải streaming trên primary khi số lượng replica lớn.

Cơ chế hoạt động bên dưới

Luồng dữ liệu diễn ra như sau:

1. App ghi vào Primary.
2. Primary ghi vào change log - WAL (Write-Ahead Log) với PostgreSQL, binlog với MySQL.
3. Replica kết nối và stream change log liên tục từ Primary.
4. Replica replay từng thay đổi theo đúng thứ tự.
5. Replica phục vụ read queries từ trạng thái đã được replay.

Toàn bộ quá trình xảy ra liên tục, không cần can thiệp thủ công.

Synchronous, Semi-sync hay Asynchronous?

Đây là đánh đổi quan trọng nhất khi cấu hình replication:

Hầu hết SaaS chọn semi-synchronous: ít nhất 1 replica phải xác nhận đã nhận log trước khi primary báo write thành công. Mất một chút latency, đổi lấy sự an tâm.

Những cạm bẫy thường gặp

Replication không phải viên đạn bạc. Sáu vấn đề cần theo dõi:

• Replica lag: Replica tụt sau primary khi có write burst hoặc mạng kém. Đọc từ replica lúc này trả dữ liệu cũ - stale reads.
• Failover phức tạp: Promote replica thủ công dễ sai. Dùng tool như Patroni hoặc pg_auto_failover để tự động hóa.
• Split-brain: Sau network partition, cả hai node đều nghĩ mình là primary và nhận writes. Cần consensus mechanism (Raft, Paxos) hoặc fencing để tránh.
• Write scaling không giải quyết được: Replication chỉ scale reads. Nếu writes là bottleneck - cần sharding.
• Không phải backup: DDL như DROP TABLE replicate ngay lập tức sang tất cả replicas. Cần PITR snapshots riêng để rollback.
• Monitoring bắt buộc: Theo dõi LSN gap và replay lag liên tục. Lag tăng đột biến là dấu hiệu sớm của vấn đề.

Lộ trình 5 bước từ zero đến production-grade

1. Thêm async read replica - bước đơn giản nhất, giảm tải primary ngay lập tức.
2. Triển khai automated failover - không để ops team promote tay lúc 3 giờ sáng.
3. Chuyển sang semi-synchronous - tăng độ an toàn data mà không hy sinh nhiều throughput.
4. Deploy cross-region replica - disaster recovery thực sự, không chỉ nằm trên slide deck.
5. Shard hoặc migrate sang Raft-native DB - khi writes là bottleneck thực sự (CockroachDB, TiDB, YugabyteDB).

Kết

Replication cải thiện hệ thống - nhưng không xóa bỏ việc phải suy nghĩ về kiến trúc. Nó chỉ thay đổi vấn đề nào bạn được phép có.

Bắt đầu với async replica đơn giản. Đo replica lag. Triển khai automated failover sớm hơn bạn nghĩ cần. Và đừng nhầm replication với backup.

Nguồn: donniechu.com.