Hogyan tervezel multi-region DB-t HA-hoz és DR-hez?

Question

IT Interview Practice · Accepted Answer

Replikáld az adatbázist régiók között és válaszd a topológiát igény szerint: **active-passive** (egy író, egy meleg standby, amely átveszi failover esetén) az egyszerűségért és erős konzisztenciáért, vagy **active-active** (több író) az alacsony írási latenciáért a konfliktusfeloldás áráért — majd válassz **sync vs async replikációt**, hogy a tartósságot a latenciáért cseréld, és definiálj explicit **RPO/RTO** célokat, amelyek a failovert vezérlik.

```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

Az **active-passive**-nak egy primaryje van, amely az írásokat kezeli, és standbyjai, amelyek csak olvasnak; hiba esetén **előléptetsz** egy standbyt. Egyszerű és elkerüli az írási konfliktusokat, de a passzív kapacitás tétlenül ül és a failovernek van egy rése. Az **active-active** minden régiónak megengedi az írások elfogadását a lokális latenciáért és failover-előléptetés nélkül — de két régió konkurensen szerkesztheti ugyanazt a sort, ezért *muszáj* feloldanod a konfliktusokat (last-write-wins, CRDT-k, vagy app-szintű merge). A legtöbb csapat active-passive-vel kezd; az active-active a globális írási latenciáért van, amit valóban nem tudsz máshogy elérni.

## Sync vs async replikáció

Ez a fő tartósság/latencia kompromisszum. **Szinkron:** a primary megvárja a távoli replika visszaigazolását a commit előtt — **RPO = 0** (nincs adatvesztés failovernél) de minden írás cross-region körutat fizet (~tíz ms), és ha a replika elérhetetlen, az írások elakadnak. **Aszinkron:** a primary lokálisan commitál és utána szállítja a változásokat — gyors írások, de egy régió-vesztés elveszítheti az utolsó néhány másodpercet (**RPO > 0**). A cross-region sync gyakran túl lassú, ezért sokan async-ot futtatnak és elfogadnak egy kis RPO-t.

## Failover, RPO és RTO

- **RPO (Recovery Point Objective):** mennyi adatot veszíthetsz — a sync vs async állítja be.
- **RTO (Recovery Time Objective):** mennyi idő, amíg visszatérsz — az állítja be, milyen gyorsan detektálsz hibát és léptetsz elő.
- Failover = detektál (health checkek) → előlépteti a standbyt → átirányítja a forgalmat (DNS/global LB). Automatizáld, de védekezz a **split-brain** ellen (mindkét régió azt hiszi, hogy ő a primary) egy quorummal/fencing tokennel.

## Interjú szemszög

A vizsgálat: érted-e, hogy a HA/DR egy **kompromisszum a konzisztencia, latencia és adatvesztés között** — nem "csak adj hozzá egy replikát". Jó: active-passive egy standbyval. Kiváló: kimondod az RPO/RTO-t, a sync-vs-async implikációkat, és a split-brain kockázatot. Csapda: azt állítani, hogy az async nulla adatvesztést ad, vagy azt feltételezni, hogy a failover azonnali és veszteségmentes.

## Kompromisszumok és hibamódok

- **Split-brain:** egy hálózati partíció két primaryt léptet elő → szétváló adat. Használj quorumot, fencinget, vagy egy witness régiót.
- **A failback nehéz:** miután a régi primary visszatér, a szétváló írások egyeztetése manuális és hibára hajlamos.
- **Költség:** a valódi multi-region nagyjából duplázza az infrát és cross-region egress sávszélesség-számlákat ad hozzá.
- **A nem tesztelt failover meghiúsul:** a sosem gyakorolt DR nem működik a valódi kiesésben — futtass game-day-eket.

Active-passive vs active-active

Sync vs async replikáció

Failover, RPO és RTO

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések