Miten suunnittelet multi-region-tietokannan HA:ta ja DR:ää varten?

Question

IT Interview Practice · Accepted Answer

Replikoi tietokanta alueiden yli ja valitse topologia tarpeen mukaan: **active-passive** (yksi kirjoittaja, lämmin standby, joka ottaa vallan failoverissa) yksinkertaisuuteen ja vahvaan konsistenssiin, tai **active-active** (useita kirjoittajia) matalaan kirjoituslatenssiin konfliktinratkaisun kustannuksella — valitse sitten **sync vs async -replikointi** vaihtaaksesi kestävyyttä latenssiin, ja määrittele eksplisiittiset **RPO/RTO**-tavoitteet, jotka ohjaavat failoveria.

```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-passivessa** on yksi primary, joka käsittelee kirjoitukset, ja standbyt, jotka vain lukevat; vikatilanteessa **ylennät** standbyn. Se on yksinkertainen ja välttää kirjoituskonfliktit, mutta passiivinen kapasiteetti on jouten ja failoverissa on aukko. **Active-active** antaa jokaisen alueen ottaa vastaan kirjoituksia paikalliseen latenssiin ilman failover-ylennystä — mutta kaksi aluetta voi muokata samaa riviä samanaikaisesti, joten sinun *täytyy* ratkaista konfliktit (last-write-wins, CRDT:t tai sovellustason merge). Useimmat tiimit aloittavat active-passivella; active-active on globaaliin kirjoituslatenssiin, jota et aidosti muuten pysty saavuttamaan.

## Sync vs async -replikointi

Tämä on ydin kestävyys-/latenssi-kompromissi. **Synkroninen:** primary odottaa etäreplikan kuittausta ennen committia — **RPO = 0** (ei datamenetystä failoverissa) mutta jokainen kirjoitus maksaa cross-region-edestakaisen matkan latenssin (~kymmeniä ms), ja jos replika ei ole tavoitettavissa, kirjoitukset pysähtyvät. **Asynkroninen:** primary committoi paikallisesti ja lähettää muutokset jälkeenpäin — nopeat kirjoitukset, mutta alueen menetys voi menettää viimeiset muutamat sekunnit (**RPO > 0**). Cross-region-sync on usein liian hidas, joten monet ajavat asyncia ja hyväksyvät pienen RPO:n.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** kuinka paljon dataa voit menettää — asetettu sync vs async -valinnalla.
- **RTO (Recovery Time Objective):** kuinka kauan kunnes olet takaisin — asetettu sillä, kuinka nopeasti havaitset vian ja ylennät.
- Failover = havaitse (health checkit) → ylennä standby → uudelleenreititä liikenne (DNS/global LB). Automatisoi se, mutta suojaudu **split-brainilta** (molemmat alueet luulevat olevansa primary) kvorumilla/fencing-tokenilla.

## Haastattelunäkökulma

Tutkinta: ymmärrätkö että HA/DR on **kompromissi konsistenssin, latenssin ja datamenetyksen välillä** — ei "lisää vain replika". Hyvä: active-passive standbyllä. Loistava: kerrot RPO/RTO:n, sync-vs-async-vaikutukset ja split-brain-riskin. Ansa: väittää että async antaa nolla datamenetystä, tai olettaa että failover on välitön ja häviötön.

## Kompromissit ja virhetilanteet

- **Split-brain:** verkkopartitio ylentää kaksi primaryä → eroava data. Käytä kvorumia, fencingiä tai witness-aluetta.
- **Failback on vaikea:** vanhan primaryn palattua eroavien kirjoitusten täsmäytys on manuaalista ja virhealtista.
- **Kustannus:** todellinen multi-region suunnilleen tuplaa infran ja lisää cross-region-egress-kaistalaskut.
- **Testaamaton failover epäonnistuu:** DR, jota ei koskaan harjoitella, ei toimi oikeassa katkossa — aja game-day-harjoituksia.

Active-passive vs active-active

Sync vs async -replikointi

Failover, RPO & RTO

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset