Bagaimana anda mereka bentuk DB multi-region untuk HA dan DR?

Question

IT Interview Practice · Accepted Answer

Replikasi database merentas wilayah dan pilih topologi anda mengikut keperluan: **active-passive** (satu penulis, sebuah warm standby yang mengambil alih pada failover) untuk kesederhanaan dan konsistensi kuat, atau **active-active** (berbilang penulis) untuk latency penulisan rendah dengan kos resolusi konflik — kemudian pilih **sync vs async replication** untuk menukar durability dengan latency, dan takrifkan sasaran **RPO/RTO** eksplisit yang memacu 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** mempunyai satu primary mengendalikan penulisan dan standby yang hanya membaca; pada kegagalan anda **menaikkan (promote)** sebuah standby. Ia mudah dan mengelakkan konflik penulisan, tetapi kapasiti pasif terbiar dan failover mempunyai jurang. **Active-active** membenarkan setiap wilayah menerima penulisan untuk latency setempat dan tiada promosi failover — tetapi dua wilayah boleh menyunting baris yang sama serentak, jadi anda *mesti* menyelesaikan konflik (last-write-wins, CRDT, atau merge peringkat app). Kebanyakan pasukan bermula active-passive; active-active untuk latency penulisan global yang anda benar-benar tidak boleh capai sebaliknya.

## Sync vs async replication

Inilah pertukaran durability/latency teras. **Synchronous:** primary menunggu replica jauh mengakui (ack) sebelum commit — **RPO = 0** (tiada kehilangan data pada failover) tetapi setiap penulisan membayar latency round-trip rentas wilayah (~puluhan ms), dan jika replica tidak boleh dicapai, penulisan terhenti. **Asynchronous:** primary commit setempat dan menghantar perubahan selepas itu — penulisan pantas, tetapi kehilangan wilayah boleh kehilangan beberapa saat terakhir (**RPO > 0**). Sync rentas wilayah selalunya terlalu perlahan, jadi ramai menjalankan async dan menerima RPO kecil.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** berapa banyak data yang anda boleh hilang — ditetapkan oleh sync vs async.
- **RTO (Recovery Time Objective):** berapa lama sehingga anda kembali — ditetapkan oleh berapa cepat anda mengesan kegagalan dan menaikkan.
- Failover = mengesan (health check) → menaikkan standby → menghala semula trafik (DNS/global LB). Automasikan ia, tetapi berjaga terhadap **split-brain** (kedua-dua wilayah menyangka merekalah primary) dengan quorum/fencing token.

## Perspektif temu duga

Siasatannya: adakah anda memahami bahawa HA/DR ialah **pertukaran antara konsistensi, latency, dan kehilangan data** — bukan "tambah sahaja replica". Baik: active-passive dengan sebuah standby. Hebat: anda menyatakan RPO/RTO, implikasi sync-vs-async, dan risiko split-brain. Perangkap: mendakwa async memberi sifar kehilangan data, atau menganggap failover serta-merta dan tanpa kehilangan.

## Pertukaran & mod kegagalan

- **Split-brain:** partition rangkaian menaikkan dua primary → data menyimpang. Guna quorum, fencing, atau witness region.
- **Failback sukar:** selepas primary lama kembali, merekonsiliasi penulisan yang menyimpang adalah manual dan mudah ralat.
- **Kos:** multi-region sebenar hampir menggandakan infra dan menambah bil bandwidth egress rentas wilayah.
- **Failover tidak diuji gagal:** DR yang tidak pernah dilatih tidak akan berfungsi dalam gangguan sebenar — jalankan game-day.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan