Migrér en 10TB database med zero downtime: hvad er planen?

Question

IT Interview Practice · Accepted Answer

**Dual-write til gammel og ny, backfill historik i baggrunden, brug CDC til at indhente halen, verificér med shadow reads, flip så reads atomart — med en rollback-path ved hvert trin.** Du tager aldrig appen ned; du kører begge databaser parallelt, indtil den nye er beviseligt identisk, og cutter så over.

## Arkitektur

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

## Sådan virker det

1. **Dual-write.** Appen skriver hver ændring til både OLD og NEW. Nye rows forbliver i sync fra nu af; kun historik mangler.
2. **Backfill.** Et baggrundsjob kopierer historiske rows i batches (throttlet for at beskytte prod). Brug `INSERT ... ON CONFLICT DO NOTHING` så det er idempotent og sikkert at genkøre.
3. **CDC catch-up.** Dual-write kan misse rows skrevet under switch-on. **Debezium** der streamer OLD DB'ens WAL/binlog replayer hver ændring og lukker gabet, backfillen ikke kan.
4. **Shadow reads.** Læs fra NEW parallelt med OLD, **sammenlign resultater**, og udsend en diff-metric. Nul diffs over tid = NEW er troværdig.
5. **Cutover.** Flip et feature flag så reads (så writes) går til NEW. Det er en config-ændring, ikke en deploy — øjeblikkelig, og **reversibel ved at flippe tilbage**.

## Interview-perspektiv

Intervieweren vil have **hvordan du garanterer intet datatab og ingen downtime**, og om du har en **rollback**. Gode svar nævner dual-write; fremragende svar tilføjer **CDC til at fange race-vinduet**, **shadow reads til at verificere før du stoler på det**, og et **atomart, reversibelt flag-flip**. Den klassiske fælde er "backfill så skift" uden verifikation — du opdager mismatchet, efter brugere ramte det, uden vej tilbage.

## Trade-offs & fejl

- **Dual-write-konsistens.** Hvis NEW-write'et fejler, men OLD lykkes, divergerer de. Gør OLD autoritativ og lad CDC reparere NEW, frem for at fejle brugerens request.
- **Omkostning & kompleksitet.** At køre to databaser + CDC + backfill er dyrt og driftstungt — kun retfærdiggjort for store, kritiske stores.
- **Skemaændringer** under migrering multiplicerer risiko; frys skema indtil cutover.
- **Backfill-belastning.** En uthrottlet backfill kan mætte prod-I/O og forårsage et udfald — det modsatte af målet; batch og rate-limit.
- **Rollback-vindue.** Bliv ved med at dual-write (nu NEW→OLD) i dage efter cutover, så du kan flippe tilbage, hvis en latent bug dukker op. Først da decommission OLD.
- **Hvornår ikke:** en lille DB med et vedligeholdelsesvindue kræver ikke dette — en 30-minutters `pg_dump`/restore er enklere og sikrere end en CDC-pipeline.

Arkitektur

Sådan virker det

Interview-perspektiv

Trade-offs & fejl

Relaterede spørgsmål