Migrer en 10TB database med null nedetid: hva er planen?

Question

IT Interview Practice · Accepted Answer

**Dual-write til gammel og ny, backfill historikk i bakgrunnen, bruk CDC for å ta igjen halen, verifiser med shadow reads, flip deretter lesninger atomisk — med en rollback-sti ved hvert steg.** Du tar aldri appen ned; du kjører begge databasene parallelt til den nye er beviselig identisk, og cutter så over.

## Arkitektur

```text
        ┌── write ──▶ GAMMEL DB (sannhetskilde) ──CDC (Debezium)──┐
 App ───┤                                                         ▼
        └── write ──▶ NY DB ◀──── backfill-jobb (historiske rader)
                        │
   shadow reads (sammenlign GAMMEL vs NY) ─▶ diff-metrikker ─▶ atomisk cutover ─▶ NY er sannhet
                                                            (flip flagg; rollback = flip tilbake)
```

## Slik fungerer det

1. **Dual-write.** Appen skriver hver endring til både GAMMEL og NY. Nye rader holder seg synkronisert fra nå; kun historikk mangler.
2. **Backfill.** En bakgrunnsjobb kopierer historiske rader i batcher (strupet for å beskytte prod). Bruk `INSERT ... ON CONFLICT DO NOTHING` slik at den er idempotent og trygg å kjøre på nytt.
3. **CDC catch-up.** Dual-write kan gå glipp av rader skrevet under påslåingen. **Debezium** som streamer GAMMEL DB-ens WAL/binlog replayer hver endring, og lukker gapet backfillen ikke kan.
4. **Shadow reads.** Les fra NY parallelt med GAMMEL, **sammenlign resultater**, og emit en diff-metrikk. Null differ over tid = NY er til å stole på.
5. **Cutover.** Flip et feature-flagg slik at lesninger (deretter writes) går til NY. Det er en config-endring, ikke en deploy — umiddelbar, og **reverserbar ved å flippe tilbake**.

## Intervjuperspektiv

Intervjueren vil ha **hvordan du garanterer ingen datatap og ingen nedetid**, og om du har en **rollback**. Gode svar nevner dual-write; utmerkede svar legger til **CDC for å fange race-vinduet**, **shadow reads for å verifisere før du stoler**, og en **atomisk, reverserbar flagg-flip**. Den klassiske fellen er "backfill deretter bytt" uten verifisering — du oppdager mismatchen etter at brukere treffer den, uten vei tilbake.

## Avveininger og feil

- **Dual-write-konsistens.** Hvis NY-writen feiler men GAMMEL lykkes, divergerer de. Gjør GAMMEL autoritativ og la CDC reparere NY, i stedet for å feile brukerens request.
- **Kostnad og kompleksitet.** Å kjøre to databaser + CDC + backfill er dyrt og operasjonelt tungt — rettferdiggjort kun for store, kritiske stores.
- **Skjemaendringer** under migrering multipliserer risiko; frys skjema til cutover.
- **Backfill-belastning.** En ustrupet backfill kan mette prod-I/O og forårsake et utfall — det motsatte av målet; batch og rate-limit.
- **Rollback-vindu.** Fortsett dual-writing (nå NY→GAMMEL) i dager etter cutover slik at du kan flippe tilbake hvis en latent bug dukker opp. Først da avvikle GAMMEL.
- **Når ikke:** en liten DB med et vedlikeholdsvindu trenger ikke dette — en 30-minutters `pg_dump`/restore er enklere og tryggere enn en CDC-pipeline.

Arkitektur

Slik fungerer det

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål