Migriere eine 10TB-Datenbank ohne Downtime: Wie sieht der Plan aus?

Question

IT Interview Practice · Accepted Answer

**Schreibe doppelt in Alt und Neu, backfille die Historie im Hintergrund, nutze CDC, um den Rest aufzuholen, verifiziere mit Shadow Reads, dann flippe die Reads atomar - mit einem Rollback-Pfad bei jedem Schritt.** Du nimmst die App nie offline; du betreibst beide Datenbanken parallel, bis die neue nachweislich identisch ist, und schaltest dann um.

## Architektur

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

## Wie es funktioniert

1. **Dual-Write.** Die App schreibt jede Änderung in OLD und NEW. Neue Rows bleiben ab jetzt synchron; nur die Historie fehlt.
2. **Backfill.** Ein Hintergrundjob kopiert historische Rows in Batches (gedrosselt, um Prod zu schützen). Nutze `INSERT ... ON CONFLICT DO NOTHING`, damit es idempotent und sicher wiederholbar ist.
3. **CDC-Aufholen.** Dual-Write kann Rows verpassen, die während des Einschaltens geschrieben werden. **Debezium**, das das WAL/Binlog der OLD DB streamt, replayt jede Änderung und schließt die Lücke, die der Backfill nicht kann.
4. **Shadow Reads.** Lies aus NEW parallel zu OLD, **vergleiche die Ergebnisse** und emittiere eine Diff-Metrik. Null Diffs über die Zeit = NEW ist vertrauenswürdig.
5. **Cutover.** Flippe ein Feature Flag, sodass Reads (dann Writes) auf NEW gehen. Es ist eine Config-Änderung, kein Deploy - sofort und **durch Zurückflippen reversibel**.

## Interview-Perspektive

Der Interviewer möchte **wie du keinen Datenverlust und keine Downtime garantierst**, und ob du ein **Rollback** hast. Gute Antworten erwähnen Dual-Write; hervorragende ergänzen **CDC, um das Race-Fenster zu fangen**, **Shadow Reads zur Verifikation vor dem Vertrauen** und einen **atomaren, reversiblen Flag-Flip**. Die klassische Falle ist "backfillen dann umschalten" ohne Verifikation - du entdeckst die Diskrepanz, nachdem Nutzer darauf stoßen, ohne Rückweg.

## Trade-offs & Fehler

- **Dual-Write-Consistency.** Scheitert der NEW-Write, während OLD gelingt, divergieren sie. Mache OLD autoritativ und lass CDC NEW reparieren, statt den Request des Nutzers scheitern zu lassen.
- **Kosten & Komplexität.** Zwei Datenbanken + CDC + Backfill zu betreiben ist teuer und betrieblich schwer - nur für große, kritische Stores gerechtfertigt.
- **Schema-Änderungen** während der Migration vervielfachen das Risiko; friere das Schema bis zum Cutover ein.
- **Backfill-Last.** Ein ungedrosselter Backfill kann die Prod-I/O sättigen und einen Ausfall verursachen - das Gegenteil des Ziels; batche und rate-limite.
- **Rollback-Fenster.** Schreibe nach dem Cutover noch tagelang doppelt (nun NEW→OLD), damit du zurückflippen kannst, falls ein latenter Bug auftaucht. Erst dann OLD außer Betrieb nehmen.
- **Wann nicht:** eine kleine DB mit einem Wartungsfenster braucht das nicht - ein 30-minütiges `pg_dump`/Restore ist einfacher und sicherer als eine CDC-Pipeline.

Architektur

Wie es funktioniert

Interview-Perspektive

Trade-offs & Fehler

Ähnliche Fragen