Migrirajte 10 TB podatkovno bazo brez izpada (zero downtime): kakšen je načrt?

Question

IT Interview Practice · Accepted Answer

**Dvojno zapisujte (dual-write) v staro in novo, v ozadju polnite (backfill) zgodovino, uporabite CDC za dohitevanje repa, preverite s senčnimi branji (shadow reads), nato atomarno preklopite branja — z rollback potjo na vsakem koraku.** Aplikacije nikoli ne ugasnete; obe podatkovni bazi tečeta vzporedno, dokler ni nova dokazljivo identična, nato preklopite.

## Arhitektura

```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)
```

## Kako deluje

1. **Dvojno zapisovanje (dual-write).** Aplikacija zapiše vsako spremembo v STARO in NOVO. Nove vrstice ostanejo sinhronizirane odslej; manjka le zgodovina.
2. **Backfill.** Job v ozadju kopira zgodovinske vrstice v paketih (throttlano za zaščito produkcije). Uporabite `INSERT ... ON CONFLICT DO NOTHING`, tako da je idempotenten in varen za ponovni zagon.
3. **CDC dohitevanje.** Dvojno zapisovanje lahko zgreši vrstice, zapisane med vklopom. **Debezium**, ki pretaka WAL/binlog STARE DB, ponovno predvaja vsako spremembo in zapre vrzel, ki je backfill ne more.
4. **Senčna branja (shadow reads).** Berite iz NOVE vzporedno s STARO, **primerjajte rezultate** in oddajajte metriko razlik (diff). Nič razlik skozi čas = NOVA je vredna zaupanja.
5. **Preklop (cutover).** Preklopite feature flag, tako da branja (nato zapisi) gredo v NOVO. To je sprememba konfiguracije, ne deploy — takojšnja in **reverzibilna z obratnim preklopom**.

## Pogled s stališča razgovora

Izpraševalec želi **kako zagotovite nič izgube podatkov in nič izpada** ter ali imate **rollback**. Dobri odgovori omenijo dvojno zapisovanje; odlični dodajo **CDC za zajem tekmovalnega okna**, **senčna branja za preverjanje pred zaupanjem** in **atomaren, reverzibilen preklop flaga**. Klasična past je "backfill nato preklopi" brez preverjanja — neujemanje odkrijete šele, ko ga uporabniki zadenejo, brez poti nazaj.

## Kompromisi in odpovedi

- **Konsistentnost dvojnega zapisovanja.** Če zapis v NOVO odpove, a v STARO uspe, se razideta. Naredite STARO avtoritativno in pustite CDC popraviti NOVO, namesto da odpoveste uporabnikovo zahtevo.
- **Strošek in kompleksnost.** Poganjanje dveh podatkovnih baz + CDC + backfill je drago in operativno težko — upravičeno le za velike, kritične shrambe.
- **Spremembe sheme** med migracijo pomnožijo tveganje; zamrznite shemo do preklopa.
- **Obremenitev backfilla.** Nethrottlan backfill lahko nasiti produkcijski I/O in povzroči izpad — nasprotje cilja; paketirajte in rate-limitajte.
- **Rollback okno.** Ohranjajte dvojno zapisovanje (zdaj NOVO→STARO) še dneve po preklopu, da lahko preklopite nazaj, če se pojavi latentna napaka. Šele nato razgradite STARO.
- **Kdaj ne:** majhna DB z vzdrževalnim oknom tega ne potrebuje — 30-minutni `pg_dump`/restore je enostavnejši in varnejši kot CDC cevovod.

Arhitektura

Kako deluje

Pogled s stališča razgovora

Kompromisi in odpovedi

Povezana vprašanja