Thiết kế DB đa vùng cho HA và DR như thế nào?

Question

IT Interview Practice · Accepted Answer

Replicate database qua nhiều region và chọn topology theo nhu cầu: **active-passive** (một writer, một standby ấm tiếp quản khi failover) cho sự đơn giản và tính nhất quán mạnh, hoặc **active-active** (nhiều writer) cho độ trễ ghi thấp đổi lại phải giải quyết conflict — rồi chọn **sync vs async replication** để cân giữa độ bền và độ trễ, và định rõ mục tiêu **RPO/RTO** dẫn dắt failover.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive** có một primary xử lý ghi và các standby chỉ đọc; khi hỏng thì bạn **promote** một standby. Nó đơn giản và tránh conflict ghi, nhưng năng lực passive nằm không và failover có một khoảng trống. **Active-active** cho mỗi region nhận ghi để có độ trễ nội vùng và khỏi promote khi failover — nhưng hai region có thể sửa cùng một row đồng thời, nên bạn *bắt buộc* phải giải quyết conflict (last-write-wins, CRDT, hoặc merge ở tầng app). Đa số team bắt đầu với active-passive; active-active dành cho khi độ trễ ghi toàn cầu thực sự không thể đạt bằng cách khác.

## Sync vs async replication

Đây là đánh đổi độ bền/độ trễ cốt lõi. **Đồng bộ:** primary chờ replica từ xa xác nhận trước khi commit — **RPO = 0** (không mất dữ liệu khi failover) nhưng mỗi lần ghi phải trả round-trip xuyên vùng (~vài chục ms), và nếu replica không truy cập được thì ghi bị đình. **Bất đồng bộ:** primary commit cục bộ rồi mới gửi thay đổi đi — ghi nhanh, nhưng mất một region có thể mất vài giây cuối (**RPO > 0**). Sync xuyên vùng thường quá chậm, nên nhiều nơi chạy async và chấp nhận một RPO nhỏ.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** bạn có thể mất bao nhiêu dữ liệu — quyết bởi sync vs async.
- **RTO (Recovery Time Objective):** bao lâu thì trở lại được — quyết bởi tốc độ phát hiện hỏng và promote.
- Failover = phát hiện (health check) → promote standby → chuyển hướng traffic (DNS/global LB). Tự động hoá nó, nhưng phòng **split-brain** (cả hai region đều tưởng mình là primary) bằng quorum/fencing token.

## Góc nhìn phỏng vấn

Điều dò: bạn có hiểu HA/DR là một **đánh đổi giữa tính nhất quán, độ trễ và mất dữ liệu** không — chứ không phải "cứ thêm một replica". Khá: active-passive với một standby. Xuất sắc: bạn nêu RPO/RTO, hệ quả của sync-vs-async, và rủi ro split-brain. Bẫy: khẳng định async cho mất-dữ-liệu-bằng-không, hoặc giả định failover tức thời và không mất mát.

## Đánh đổi & kịch bản hỏng

- **Split-brain:** phân mảnh mạng promote hai primary → dữ liệu phân kỳ. Dùng quorum, fencing, hoặc một witness region.
- **Failback khó:** sau khi primary cũ quay lại, hoà giải các lần ghi phân kỳ là việc thủ công và dễ sai.
- **Chi phí:** đa vùng thật sự gần như gấp đôi hạ tầng và thêm hoá đơn băng thông egress xuyên vùng.
- **Failover chưa test sẽ hỏng:** DR chưa bao giờ diễn tập sẽ không chạy trong sự cố thật — hãy làm game-day.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Góc nhìn phỏng vấn

Đánh đổi & kịch bản hỏng

Câu hỏi liên quan