Cách Replication trong Cơ sở dữ liệu Hoạt động

Replication là gì?

Replication (Sao chép) là quá trình sao chép và duy trì dữ liệu cơ sở dữ liệu (Database Data) trên nhiều máy chủ (Servers/Nodes). Thay vì lưu trữ dữ liệu trên một máy duy nhất, Replication phân phối bản sao (Copies) đến nhiều Nodes để hệ thống có thể chịu lỗi (Survive Failures) và phục vụ nhiều người dùng hơn.

Tại sao cần Replication?

Vấn đề	Replication giúp gì
Hỏng hóc phần cứng (Hardware Failure)	Nếu một Node bị hỏng, Node khác vẫn có bản sao — hệ thống tiếp tục hoạt động
Khả năng mở rộng đọc (Read Scalability)	Phân phối truy vấn đọc (Read Queries) across các Replica thay vì quá tải một máy chủ
Độ trễ (Latency)	Đặt Replica ở gần người dùng về mặt địa lý — thời gian phản hồi nhanh hơn
Bảo trì (Maintenance)	Có thể đưa một Node xuống để nâng cấp mà không gây gián đoạn (Downtime)

Thuật ngữ quan trọng (Key Terminology)

• Primary / Leader / Master — Node nhận các thao tác ghi (Write Operations)
• Replica / Follower / Slave — Node nhận bản sao dữ liệu từ Primary
• Write-Ahead Log (WAL) — Nhật ký nội bộ mà Primary gửi đến các Replica để phát lại thay đổi (Replay Changes)
• Replication Lag — Độ trễ thời gian giữa lúc ghi trên Primary và khi Replica áp dụng thay đổi đó
• Failover — Quá trình thăng cấp một Replica thành Primary khi Primary gốc bị hỏng
• Write Concern — Số Node phải xác nhận ghi trước khi Client nhận được ACK (ví dụ: w: 1 = chỉ Primary, w: majority = đa số Replica)

Cách Replication hoạt động (đơn giản hóa)

1. Client sends WRITE to Primary
2. Primary writes to its local storage + WAL
3. Primary ships the WAL entry to Replicas
4. Replicas replay the WAL entry → data is now copied
5. Replicas send ACK back (timing depends on sync/async mode)
6. Client receives confirmation

Câu hỏi quan trọng là: khi nào Client nhận được ACK? Điều này quyết định Replication là Đồng bộ (Synchronous) hay Bất đồng bộ (Asynchronous).

Trực quan hóa

Xem cách một thao tác ghi duy nhất truyền qua các mô hình Replication khác nhau. Chuyển đổi giữa các chế độ để so sánh độ trễ ghi (Write Latency), đảm bảo tính nhất quán (Consistency Guarantees) và hành vi khi xảy ra lỗi (Failure Behavior):

Primary handles all writes, waits for all replicas to confirm before ACKing the client. Strong consistency but higher write latency.

0 / 0

💻Client

│

PrimaryWrites

—

│

│

Replica AReads

—

Replica BReads

—

So sánh các chiến lược Replication

Khía cạnh	Đơn Leader Đồng bộ (Single-Leader Sync)	Đơn Leader Bất đồng bộ (Single-Leader Async)	Đa Leader (Multi-Leader)
Luồng ghi (Write Path)	Client → Primary → chờ tất cả Replica → ACK	Client → Primary → ACK ngay lập tức	Client → bất kỳ Leader → Replicate đến các Leader khác
Luồng đọc (Read Path)	Bất kỳ Replica (luôn cập nhật)	Bất kỳ Replica (có thể cũ - Stale)	Bất kỳ Replica ở bất kỳ Region
Tính nhất quán (Consistency)	Mạnh (Strong) — tất cả Node đồng ý trước ACK	Cuối cùng (Eventual) — Replica sẽ cập nhật sau	Cuối cùng (Eventual) — cần giải quyết xung đột (Conflict Resolution)
Độ trễ ghi (Write Latency)	Cao (chờ tất cả Replica)	Thấp (ACK ngay lập tức)	Thấp (ACK từ Leader cục bộ)
Khả năng mở rộng đọc	Tốt — các Replica phục vụ đọc	Tốt — các Replica phục vụ đọc	Xuất sắc — đọc phân tán across các Region
Khả năng chịu lỗi	Nếu Primary hỏng, Replica sẽ tiếp quản	Replica có thể mất dữ liệu ghi gần đây	Các Leader khác tiếp tục nhận ghi
Trường hợp sử dụng	Hệ thống tài chính, tài khoản người dùng	Phân phối nội dung, bảng điều khiển phân tích	Ứng dụng phân tán theo địa lý, Offline-first

Khi nào Replication Lag quan trọng

Trong Replication Bất đồng bộ (Asynchronous), có một khoảng thời gian mà các Replica tụt hậu so với Primary. Điều này gây ra:

• Đọc dữ liệu cũ (Stale Reads) — người dùng viết bình luận, tải lại trang và không thấy vì truy cập vào Replica chưa cập nhật
• Không nhất quán đọc-sau-ghi (Read-after-Write Inconsistency) — người dùng đã ghi dữ liệu nhưng không đọc lại được ngay lập tức
• Mất dữ liệu khi Failover — nếu Primary bị hỏng trước khi Replicate xong, các thao tác ghi đã Commit sẽ bị mất

Các giải pháp phổ biến:

1. Nhất quán đọc-ghi của chính mình (Read-your-Writes Consistency) — chuyển các lượt đọc tiếp theo của người dùng đã ghi đến Primary
2. Đọc đơn điệu (Monotonic Reads) — đảm bảo người dùng luôn đọc từ cùng một Replica (Session Stickiness)
3. Replication bán đồng bộ (Semi-Synchronous Replication) — chờ ít nhất một Replica xác nhận, sau đó mới ACK

Đơn Leader (Single-Leader) so với Đa Leader (Multi-Leader)

Đơn Leader (Single-Leader)

Mô hình đơn giản nhất. Một Node nhận tất cả thao tác ghi; các Replica chỉ phục vụ đọc.

• Dễ hiểu — không có xung đột ghi (Write Conflicts)
• Primary là điểm nghẽn (Bottleneck) cho khối lượng ghi lớn
• Failover cần thăng cấp một Replica thành Primary (tự động trong cơ sở dữ liệu được quản lý - Managed Databases)

Đa Leader (Multi-Leader)

Nhiều Node nhận ghi độc lập. Các thay đổi được đồng bộ hóa giữa các Leader.

• Ghi mở rộng theo chiều ngang (Scale Horizontally) — mỗi Region có Leader riêng
• Yêu cầu giải quyết xung đột (Conflict Resolution) khi hai Leader nhận ghi đồng thời vào cùng một dòng
• Các chiến lược giải quyết phổ biến: Last-Write-Wins (LWW), Merge ở mức ứng dụng, CRDTs

Replication trong Thực tế

• PostgreSQL: Streaming Replication (bất đồng bộ mặc định, có thể bật đồng bộ). Sử dụng WAL Shipping.
• MySQL: Binary Log Replication với các chế độ Async, Semi-sync và Group Replication.
• MongoDB: Replica Sets với Automatic Failover. Hỗ trợ điều chỉnh Write Concern (w: 1, w: majority).
• Redis: Asynchronous Replication. Sentinel cho Automatic Failover.

Tìm hiểu thêm

Đọc lý thuyết đầy đủ tại Cơ sở dữ liệu > Replication.