Kako zasnujete večregijsko podatkovno bazo za HA in DR?

Question

IT Interview Practice · Accepted Answer

Replicirajte podatkovno bazo čez regije in izberite topologijo glede na potrebo: **active-passive** (en pisec, topla rezerva, ki prevzame ob failoverju) za enostavnost in močno konsistentnost, ali **active-active** (več piscev) za nizko latenco zapisov za ceno reševanja konfliktov — nato izberite **sync proti async replikaciji**, da menjate trajnost za latenco, in definirajte eksplicitne cilje **RPO/RTO**, ki poganjajo 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 proti active-active

**Active-passive** ima eno primarno, ki obravnava zapise, in rezerve (standbys), ki le berejo; ob odpovedi **povzdignete (promote)** rezervo. Je enostavno in se izogne konfliktom zapisov, a pasivna zmogljivost miruje in failover ima vrzel. **Active-active** pusti vsaki regiji sprejemati zapise za lokalno latenco in brez failover povzdignitve — a dve regiji lahko sočasno urejata isto vrstico, zato *morate* reševati konflikte (last-write-wins, CRDT-ji ali združevanje na ravni aplikacije). Večina ekip začne z active-passive; active-active je za globalno latenco zapisov, ki je resnično ne morete doseči drugače.

## Sync proti async replikacija

To je osrednji kompromis trajnost/latenca. **Sinhrono:** primarna počaka, da oddaljena replika potrdi, preden potrdi (commit) — **RPO = 0** (brez izgube podatkov ob failoverju), a vsak zapis plača medregijski krožni obhod (~desetine ms), in če je replika nedosegljiva, se zapisi ustavijo. **Asinhrono:** primarna potrdi lokalno in pošlje spremembe pozneje — hitri zapisi, a izguba regije lahko izgubi zadnjih nekaj sekund (**RPO > 0**). Medregijski sync je pogosto prepočasen, zato mnogi poganjajo async in sprejmejo majhen RPO.

## Failover, RPO in RTO

- **RPO (Recovery Point Objective):** koliko podatkov lahko izgubite — nastavljeno s sync proti async.
- **RTO (Recovery Time Objective):** kako dolgo do vrnitve — nastavljeno s tem, kako hitro zaznate odpoved in povzdignete.
- Failover = zaznaj (health checki) → povzdigni rezervo → preusmeri promet (DNS/global LB). Avtomatizirajte, a se zavarujte pred **razcepljenimi možgani (split-brain)** (obe regiji mislita, da sta primarni) s kvorumom/fencing tokenom.

## Pogled s stališča razgovora

Preverjajo: ali razumete, da je HA/DR **kompromis med konsistentnostjo, latenco in izgubo podatkov** — ne "kar dodaj repliko". Dobro: active-passive z rezervo. Odlično: navedete RPO/RTO, implikacije sync-proti-async in tveganje split-brain. Past: trditev, da async da nič izgube podatkov, ali domneva, da je failover takojšen in brez izgube.

## Kompromisi in načini odpovedi

- **Split-brain:** mrežna particija povzdigne dve primarni → razidoči se podatki. Uporabite kvorum, fencing ali pričevalno (witness) regijo.
- **Failback je težek:** ko se stara primarna vrne, je usklajevanje razidočih se zapisov ročno in nagnjeno k napakam.
- **Strošek:** pravi večregijski postroj približno podvoji infrastrukturo in doda medregijske egress račune za pasovno širino.
- **Netestiran failover odpove:** DR, ki nikoli ni bil odigran (drilled), ne bo deloval v pravem izpadu — izvajajte game-daye.

Active-passive proti active-active

Sync proti async replikacija

Failover, RPO in RTO

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja