Kaip suprojektuoti kelių regionų DB aukštam prieinamumui (HA) ir DR?

Question

IT Interview Practice · Accepted Answer

Replikuokite duomenų bazę per regionus ir pasirinkite topologiją pagal poreikį: **active-passive** (vienas rašytojas, šilta standby, perimanti gedimo atveju) paprastumui ir stipriai konsistencijai, arba **active-active** (keli rašytojai) mažai įrašymo latency mainais į konfliktų sprendimą — tada pasirinkite **sync vs async replikaciją**, kad kompromisuotumėte patvarumą su latency, ir apibrėžkite aiškius **RPO/RTO** tikslus, valdančius 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** turi vieną primary, tvarkantį įrašymus, ir standby, kurie tik skaito; gedimo atveju **paaukštinate** standby. Tai paprasta ir vengia įrašymo konfliktų, bet pasyvi talpa sėdi tuščia, o failover turi tarpą. **Active-active** leidžia kiekvienam regionui priimti įrašymus lokaliai latency ir jokio failover paaukštinimo — bet du regionai gali redaguoti tą pačią eilutę lygiagrečiai, tad *privalote* spręsti konfliktus (last-write-wins, CRDTs arba app-lygio merge). Dauguma komandų pradeda nuo active-passive; active-active yra globaliai įrašymo latency, kurios kitaip tikrai negalite pasiekti.

## Sync vs async replikacija

Tai pagrindinis patvarumo/latency kompromisas. **Sinchroninė:** primary laukia, kol nutolusi replika patvirtins prieš commit — **RPO = 0** (jokio duomenų praradimo failover metu), bet kiekvienas įrašymas moka cross-region round-trip latency (~dešimtys ms), o jei replika nepasiekiama, įrašymai sustoja. **Asinchroninė:** primary commit lokaliai ir siunčia pokyčius po to — greiti įrašymai, bet regiono praradimas gali prarasti paskutines kelias sekundes (**RPO > 0**). Cross-region sync dažnai per lėtas, tad daugelis vykdo async ir priima mažą RPO.

## Failover, RPO ir RTO

- **RPO (Recovery Point Objective):** kiek duomenų galite prarasti — nustatomas pagal sync vs async.
- **RTO (Recovery Time Objective):** kiek laiko iki grįžimo — nustatomas pagal tai, kaip greitai aptinkate gedimą ir paaukštinate.
- Failover = aptikti (health checks) → paaukštinti standby → perkelti srautą (DNS/global LB). Automatizuokite, bet saugokitės nuo **split-brain** (abu regionai mano, kad jie primary) su quorum/fencing token.

## Interviu perspektyva

Tiriama: ar suprantate, kad HA/DR yra **kompromisas tarp konsistencijos, latency ir duomenų praradimo** — ne „tiesiog pridėti repliką". Gerai: active-passive su standby. Puikiai: nurodote RPO/RTO, sync-vs-async pasekmes ir split-brain riziką. Spąstai: teigti, kad async duoda nulinį duomenų praradimą, arba manyti, kad failover akimirksninis ir be praradimų.

## Kompromisai ir gedimai

- **Split-brain:** tinklo skaidymas paaukština du primary → išsiskyrę duomenys. Naudokite quorum, fencing arba witness regioną.
- **Failback sunkus:** senam primary grįžus, išsiskyrusių įrašymų suderinimas yra rankinis ir klaidingas.
- **Kaina:** tikras kelių regionų maždaug dvigubina infrastruktūrą ir prideda cross-region egress bandwidth sąskaitas.
- **Neišbandytas failover žlunga:** DR, kuris niekada nepratimuotas, neveiks realiame gedime — vykdykite game-days.

Active-passive vs active-active

Sync vs async replikacija

Failover, RPO ir RTO

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai