Migrează o bază de date de 10TB cu zero downtime: care este planul?

Question

IT Interview Practice · Accepted Answer

**Fă dual-write către vechi și nou, fă backfill la istoric în fundal, folosește CDC pentru a prinde din urmă coada, verifică cu shadow reads, apoi comută citirile atomic — cu o cale de rollback la fiecare pas.** Nu oprești niciodată aplicația; rulezi ambele baze de date în paralel până când cea nouă este dovedit identică, apoi faci cutover.

## Arhitectură

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

## Cum funcționează

1. **Dual-write.** Aplicația scrie fiecare modificare atât în OLD, cât și în NEW. Rândurile noi rămân sincronizate de acum înainte; doar istoricul lipsește.
2. **Backfill.** Un job de fundal copiază rândurile istorice în batch-uri (throttlate pentru a proteja producția). Folosește `INSERT ... ON CONFLICT DO NOTHING`, astfel încât să fie idempotent și sigur de re-rulat.
3. **CDC catch-up.** Dual-write-ul poate rata rânduri scrise în timpul pornirii comutării. **Debezium**, transmițând WAL/binlog-ul OLD DB, face replay la fiecare modificare, închizând golul pe care backfill-ul nu îl poate.
4. **Shadow reads.** Citește din NEW în paralel cu OLD, **compară rezultatele** și emite o metrică de diferență. Zero diferențe în timp = NEW este de încredere.
5. **Cutover.** Comută un feature flag, astfel încât citirile (apoi scrierile) să meargă către NEW. Este o schimbare de config, nu un deploy — instantaneu și **reversibil prin comutare înapoi**.

## Perspectiva de interviu

Intervievatorul vrea **cum garantezi zero pierdere de date și zero downtime** și dacă ai un **rollback**. Răspunsurile bune menționează dual-write; cele excelente adaugă **CDC pentru a prinde fereastra de race**, **shadow reads pentru a verifica înainte de a avea încredere** și o **comutare de flag atomică, reversibilă**. Capcana clasică este "backfill apoi comută" fără verificare — descoperi nepotrivirea după ce utilizatorii o lovesc, fără cale de întoarcere.

## Compromisuri și eșecuri

- **Consistența dual-write.** Dacă scrierea în NEW eșuează, dar OLD reușește, ele diverg. Fă OLD autoritar și lasă CDC să repare NEW, în loc să eșuezi request-ul utilizatorului.
- **Cost și complexitate.** Rularea a două baze de date + CDC + backfill este scumpă și grea operațional — justificată doar pentru store-uri mari, critice.
- **Modificările de schemă** în timpul migrării multiplică riscul; îngheață schema până la cutover.
- **Încărcarea de backfill.** Un backfill nethrottlat poate satura I/O-ul de producție și cauza o cădere — opusul scopului; fă batch și rate-limit.
- **Fereastra de rollback.** Continuă dual-write-ul (acum NEW→OLD) zile după cutover, astfel încât să poți comuta înapoi dacă apare un bug latent. Abia apoi dezafectează OLD.
- **Când nu:** o bază de date mică cu o fereastră de mentenanță nu are nevoie de asta — un `pg_dump`/restore de 30 de minute este mai simplu și mai sigur decât un pipeline CDC.

Arhitectură

Cum funcționează

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe