Migroi 10 TB tietokanta ilman käyttökatkoa: mikä on suunnitelma?

Question

IT Interview Practice · Accepted Answer

**Kaksoiskirjoita (dual-write) vanhaan ja uuteen, backfillaa historia taustalla, käytä CDC:tä hännän kiinnikuromiseen, verifioi shadow readeilla, käännä sitten lukemiset atomisesti — rollback-polku joka askeleessa.** Et koskaan ota sovellusta alas; ajat molempia tietokantoja rinnakkain, kunnes uusi on todistetusti identtinen, sitten cutover.

## Arkkitehtuuri

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## Miten se toimii

1. **Dual-write.** Sovellus kirjoittaa jokaisen muutoksen sekä OLD:iin että NEW:hun. Uudet rivit pysyvät synkassa tästä eteenpäin; vain historia puuttuu.
2. **Backfill.** Taustatyö kopioi historialliset rivit erissä (throttlattu tuotannon suojaamiseksi). Käytä `INSERT ... ON CONFLICT DO NOTHING`, jotta se on idempotentti ja turvallinen ajaa uudelleen.
3. **CDC catch-up.** Dual-write voi ohittaa rivejä, jotka kirjoitettiin kytkennän aikana. **Debezium**, joka striimaa OLD-DB:n WAL/binlogia, toistaa jokaisen muutoksen sulkien aukon, jota backfill ei voi.
4. **Shadow reads.** Lue NEW:sta rinnakkain OLD:in kanssa, **vertaile tuloksia** ja lähetä diff-metriikka. Nolla diffiä ajan myötä = NEW on luotettava.
5. **Cutover.** Käännä feature flag, jotta lukemiset (sitten kirjoitukset) menevät NEW:hun. Se on konfiguraatiomuutos, ei deploy — välitön, ja **peruttavissa kääntämällä takaisin**.

## Haastattelunäkökulma

Haastattelija haluaa **miten takaat ettei dataa menetetä ja ettei käyttökatkoa tule**, ja onko sinulla **rollback**. Hyvät vastaukset mainitsevat dual-writen; loistavat lisäävät **CDC:n kilpailuikkunan kiinnisaamiseen**, **shadow readit verifioimaan ennen luottamista** ja **atomisen, peruttavan flag-käännön**. Klassinen ansa on "backfill sitten vaihda" ilman verifiointia — löydät epäsuhdan sen jälkeen kun käyttäjät osuvat siihen, ilman paluutietä.

## Kompromissit ja virhetilanteet

- **Dual-write-konsistenssi.** Jos NEW-kirjoitus epäonnistuu mutta OLD onnistuu, ne eroavat. Tee OLD:sta auktoritatiivinen ja anna CDC:n korjata NEW, sen sijaan että hylkäisit käyttäjän pyynnön.
- **Kustannus & monimutkaisuus.** Kahden tietokannan + CDC:n + backfillin ajaminen on kallista ja operatiivisesti raskasta — perusteltua vain suurille, kriittisille storeille.
- **Skeemamuutokset** migraation aikana moninkertaistavat riskin; jäädytä skeema cutoveriin asti.
- **Backfill-kuorma.** Throttlaamaton backfill voi saturoida tuotannon I/O:n ja aiheuttaa katkon — tavoitteen vastakohta; batchaa ja rate-limitoi.
- **Rollback-ikkuna.** Jatka dual-writea (nyt NEW→OLD) päiviä cutoverin jälkeen, jotta voit kääntää takaisin, jos piilevä bugi ilmenee. Vasta sitten poista OLD käytöstä.
- **Milloin ei:** pieni DB huoltoikkunalla ei tarvitse tätä — 30 minuutin `pg_dump`/restore on yksinkertaisempi ja turvallisempi kuin CDC-pipeline.

Arkkitehtuuri

Miten se toimii

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset