Jak zaprojektować bazę wieloregionową dla HA i DR?

Question

IT Interview Practice · Accepted Answer

Replikuj bazę między regionami i wybierz topologię wg potrzeby: **active-passive** (jeden writer, ciepły standby przejmujący przy failoverze) dla prostoty i silnej spójności, albo **active-active** (wiele writerów) dla niskiego latency zapisu kosztem rozstrzygania konfliktów — potem wybierz **sync vs async replication**, aby zbalansować trwałość względem latency, i zdefiniuj jawne cele **RPO/RTO** napędzające 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** ma jeden primary obsługujący zapisy i standby'e tylko do odczytu; przy awarii **promujesz** standby. Jest prosty i unika konfliktów zapisu, ale pasywna pojemność stoi bezczynnie, a failover ma lukę. **Active-active** pozwala każdemu regionowi przyjmować zapisy dla lokalnego latency i bez promocji failoveru — ale dwa regiony mogą jednocześnie edytować ten sam wiersz, więc *musisz* rozstrzygać konflikty (last-write-wins, CRDT lub scalanie na poziomie aplikacji). Większość zespołów zaczyna od active-passive; active-active jest dla globalnego latency zapisu, którego naprawdę nie da się osiągnąć inaczej.

## Sync vs async replication

To rdzeń kompromisu trwałość/latency. **Synchroniczna:** primary czeka na potwierdzenie zdalnej repliki przed commitem — **RPO = 0** (brak utraty danych przy failoverze), ale każdy zapis płaci za round-trip międzyregionowy (~dziesiątki ms), a jeśli replika jest nieosiągalna, zapisy się zatrzymują. **Asynchroniczna:** primary commituje lokalnie i wysyła zmiany potem — szybkie zapisy, ale utrata regionu może stracić ostatnie kilka sekund (**RPO > 0**). Sync międzyregionowy jest często zbyt wolny, więc wielu uruchamia async i akceptuje małe RPO.

## Failover, RPO i RTO

- **RPO (Recovery Point Objective):** ile danych możesz stracić — ustalane przez sync vs async.
- **RTO (Recovery Time Objective):** jak długo do powrotu — ustalane przez to, jak szybko wykrywasz awarię i promujesz.
- Failover = wykryj (health checks) → promuj standby → przekieruj ruch (DNS/global LB). Automatyzuj to, ale zabezpiecz się przed **split-brain** (oba regiony myślą, że są primary) kworum/tokenem fencingu.

## Perspektywa rozmowy kwalifikacyjnej

Sonda: czy rozumiesz, że HA/DR to **kompromis między spójnością, latency i utratą danych** — a nie „po prostu dodaj replikę". Dobrze: active-passive ze standby. Świetnie: podajesz RPO/RTO, implikacje sync-vs-async i ryzyko split-brain. Pułapka: twierdzenie, że async daje zero utraty danych, lub zakładanie, że failover jest natychmiastowy i bezstratny.

## Kompromisy i tryby awarii

- **Split-brain:** partycja sieci promuje dwa primary → rozbieżne dane. Użyj kworum, fencingu lub regionu-świadka (witness).
- **Failback jest trudny:** po powrocie starego primary uzgadnianie rozbieżnych zapisów jest ręczne i podatne na błędy.
- **Koszt:** prawdziwa wieloregionowość mniej więcej podwaja infrastrukturę i dodaje rachunki za egress międzyregionowy.
- **Nieprzetestowany failover zawodzi:** DR, którego nigdy nie ćwiczono, nie zadziała w prawdziwej awarii — rób game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO i RTO

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania