Jak navrhnete multi-region DB pro HA a DR?

Question

IT Interview Practice · Accepted Answer

Replikujte databázi napříč regiony a zvolte topologii podle potřeby: **active-passive** (jeden writer, warm standby, který převezme při failoveru) pro jednoduchost a silnou konzistenci, nebo **active-active** (více writerů) pro nízkou latenci zápisu za cenu řešení konfliktů — pak zvolte **sync vs async replikaci** k obchodu trvanlivosti za latenci a definujte explicitní cíle **RPO/RTO** řídící 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** má jeden primary obsluhující zápisy a standby, které jen čtou; při selhání **povýšíte** standby. Je to jednoduché a vyhýbá se konfliktům zápisu, ale pasivní kapacita zahálí a failover má mezeru. **Active-active** nechá každý region přijímat zápisy pro lokální latenci a žádné povýšení při failoveru — ale dva regiony mohou editovat stejný řádek souběžně, takže *musíte* řešit konflikty (last-write-wins, CRDT, nebo merge na úrovni aplikace). Většina týmů začíná active-passive; active-active je pro globální latenci zápisu, kterou jinak skutečně nesplníte.

## Sync vs async replikace

Toto je jádrový kompromis trvanlivosti/latence. **Synchronní:** primary čeká na potvrzení vzdálené repliky před commitem — **RPO = 0** (žádná ztráta dat při failoveru), ale každý zápis platí cross-region round-trip latenci (~desítky ms), a pokud je replika nedostupná, zápisy se zastaví. **Asynchronní:** primary commituje lokálně a posílá změny poté — rychlé zápisy, ale ztráta regionu může ztratit poslední pár sekund (**RPO > 0**). Cross-region sync je často příliš pomalý, takže mnozí běží async a akceptují malé RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** kolik dat můžete ztratit — dáno sync vs async.
- **RTO (Recovery Time Objective):** jak dlouho, než jste zpět — dáno tím, jak rychle detekujete selhání a povýšíte.
- Failover = detekce (health checks) → povýšení standby → přesměrování provozu (DNS/global LB). Automatizujte to, ale chraňte se před **split-brainem** (oba regiony se považují za primary) kvórem/fencing tokenem.

## Pohled z pohovoru

Zkoumá se: chápete, že HA/DR je **kompromis mezi konzistencí, latencí a ztrátou dat** — ne „prostě přidej repliku“. Dobré: active-passive se standby. Skvělé: uvedete RPO/RTO, důsledky sync-vs-async a riziko split-brainu. Past: tvrdit, že async dá nulovou ztrátu dat, nebo předpokládat, že failover je okamžitý a bezeztrátový.

## Kompromisy a selhání

- **Split-brain:** síťová partition povýší dva primary → rozejitá data. Použijte kvórum, fencing nebo witness region.
- **Failback je těžký:** po návratu starého primary je odsouhlasení rozejitých zápisů manuální a náchylné k chybám.
- **Náklady:** skutečný multi-region zhruba zdvojnásobí infra a přidá účty za cross-region egress bandwidth.
- **Netestovaný failover selže:** DR, který se nikdy nedrilloval, ve skutečném výpadku nezafunguje — provozujte game-days.

Active-passive vs active-active

Sync vs async replikace

Failover, RPO & RTO

Pohled z pohovoru

Kompromisy a selhání

Související otázky