Migrálj egy 10TB-os adatbázist nulla leállással: mi a terv?

Question

IT Interview Practice · Accepted Answer

**Dual-write-olj a régibe és az újba, backfilleld a történelmet a háttérben, CDC-vel érd utol a maradékot, ellenőrizz shadow readekkel, majd fordítsd át az olvasásokat atomian — minden lépésnél egy rollback úttal.** Sosem állítod le az appot; párhuzamosan futtatod mindkét adatbázist, amíg az új bizonyíthatóan azonos, majd átkapcsolsz.

## Architektúra

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

## Hogyan működik

1. **Dual-write.** Az app minden változást a RÉGIBE és az ÚJBA is ír. Az új sorok mostantól szinkronban maradnak; csak a történelem hiányzik.
2. **Backfill.** Egy háttér job batchekben másolja a történelmi sorokat (throttle-ölve a prod védelmére). Használj `INSERT ... ON CONFLICT DO NOTHING`-et, hogy idempotens és biztonságosan újrafuttatható legyen.
3. **CDC utolérés.** A dual-write kihagyhat a bekapcsolás közben írt sorokat. A **Debezium**, amely a RÉGI DB WAL/binlogját streameli, minden változást replayel, bezárva a rést, amit a backfill nem tud.
4. **Shadow readek.** Olvass az ÚJBÓL a RÉGIVEL párhuzamosan, **hasonlítsd össze az eredményeket**, és emittelj egy diff metrikát. Nulla diff idővel = az ÚJ megbízható.
5. **Cutover.** Fordíts át egy feature flaget, hogy az olvasások (majd írások) az ÚJRA menjenek. Ez egy config változtatás, nem deploy — azonnali, és **visszafordítható visszafordítással**.

## Interjú szemszög

Az interjúztató azt akarja, **hogyan garantálsz nulla adatvesztést és nulla leállást**, és van-e **rollbacked**. A jó válaszok említik a dual-write-ot; a kiváló válaszok hozzáadják a **CDC-t a versenyablak elkapására**, a **shadow readeket az ellenőrzéshez a megbízás előtt**, és egy **atomi, visszafordítható flag átfordítást**. A klasszikus csapda a "backfill majd kapcsolás" ellenőrzés nélkül — az eltérést azután fedezed fel, hogy a felhasználók beleütköznek, visszaút nélkül.

## Kompromisszumok és hibák

- **Dual-write konzisztencia.** Ha az ÚJ írás meghiúsul de a RÉGI sikerül, szétválnak. Tedd a RÉGIT tekintélyessé és hagyd, hogy a CDC javítsa az ÚJAT, ahelyett hogy a felhasználó requestjét buktatnád.
- **Költség és komplexitás.** Két adatbázis + CDC + backfill futtatása drága és üzemeltetésileg nehéz — csak nagy, kritikus store-oknál indokolt.
- **A séma-változások** migráció közben megszorozzák a kockázatot; fagyaszd a sémát a cutoverig.
- **Backfill terhelés.** Egy throttleletlen backfill telítheti a prod I/O-t és kiesést okozhat — a cél ellentéte; batchelj és rate-limitelj.
- **Rollback ablak.** Tarts fenn dual-write-ot (most ÚJ→RÉGI) a cutover után napokig, hogy vissza tudj fordítani, ha egy rejtett bug felszínre kerül. Csak ekkor selejtezd a RÉGIT.
- **Mikor ne:** egy kis DB egy karbantartási ablakkal nem igényli ezt — egy 30 perces `pg_dump`/restore egyszerűbb és biztonságosabb, mint egy CDC pipeline.

Architektúra

Hogyan működik

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések