Migrace 10TB databáze s nulovým výpadkem: jaký je plán?

Question

IT Interview Practice · Accepted Answer

**Dvojitě zapisujte do staré a nové, backfillujte historii na pozadí, použijte CDC k dohnání zbytku, ověřte shadow reads, pak atomicky přepněte čtení — s cestou k rollbacku v každém kroku.** Aplikaci nikdy nevypnete; obě databáze běží paralelně, dokud není nová prokazatelně identická, pak provedete cutover.

## Architektura

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

## Jak to funguje

1. **Dvojitý zápis.** Aplikace zapisuje každou změnu do OLD i NEW. Nové řádky od teď zůstávají v synchronu; chybí jen historie.
2. **Backfill.** Job na pozadí kopíruje historické řádky v dávkách (přiškrcených kvůli ochraně produkce). Použijte `INSERT ... ON CONFLICT DO NOTHING`, aby byl idempotentní a bezpečně opakovatelný.
3. **CDC dohnání.** Dvojitý zápis může minout řádky zapsané během zapínání. **Debezium** streamující WAL/binlog OLD DB přehraje každou změnu a uzavře mezeru, kterou backfill nezvládne.
4. **Shadow reads.** Čtěte z NEW paralelně s OLD, **porovnejte výsledky** a emitujte diff metriku. Nula rozdílů v čase = NEW je důvěryhodná.
5. **Cutover.** Přepněte feature flag, aby čtení (pak zápisy) šla na NEW. Je to změna konfigurace, ne deploy — okamžitá a **vratná přepnutím zpět**.

## Pohled z pohovoru

Tazatel chce vědět **jak garantujete žádnou ztrátu dat a žádný výpadek** a zda máte **rollback**. Dobré odpovědi zmíní dvojitý zápis; skvělé přidají **CDC k zachycení race window**, **shadow reads k ověření před důvěrou** a **atomické vratné přepnutí flagu**. Klasická past je „backfill pak přepni“ bez ověření — nesoulad objevíte, až na něj uživatelé narazí, bez cesty zpět.

## Kompromisy a selhání

- **Konzistence dvojitého zápisu.** Pokud zápis do NEW selže, ale do OLD uspěje, rozejdou se. Udělejte OLD autoritativní a nechte CDC opravit NEW, místo abyste selhali požadavek uživatele.
- **Náklady a složitost.** Provoz dvou databází + CDC + backfill je drahý a provozně náročný — ospravedlnitelný jen pro velké kritické úložiště.
- **Změny schématu** během migrace znásobují riziko; zmrazte schéma až do cutoveru.
- **Zátěž backfillu.** Nepřiškrcený backfill může nasytit produkční I/O a způsobit výpadek — opak cíle; dávkujte a rate-limitujte.
- **Okno pro rollback.** Pokračujte v dvojitém zápisu (teď NEW→OLD) dny po cutoveru, abyste mohli přepnout zpět, když se objeví latentní bug. Až poté vyřaďte OLD.
- **Kdy ne:** malá DB s údržbovým oknem tohle nepotřebuje — 30minutový `pg_dump`/restore je jednodušší a bezpečnější než CDC pipeline.

Architektura

Jak to funguje

Pohled z pohovoru

Kompromisy a selhání

Související otázky