Migrera en 10TB-databas med noll nedtid: vad är planen?

Question

IT Interview Practice · Accepted Answer

**Dubbelskriv till gammal och ny, backfilla historik i bakgrunden, använd CDC för att komma ikapp svansen, verifiera med shadow reads, vänd sedan läsningar atomiskt — med en rollback-väg vid varje steg.** Du tar aldrig ner appen; du kör båda databaserna parallellt tills den nya är bevisbart identisk, sedan gör du cutover.

## 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å här fungerar det

1. **Dubbelskrivning.** Appen skriver varje ändring till både OLD och NEW. Nya rader hålls synkade från och med nu; bara historik saknas.
2. **Backfill.** Ett bakgrundsjobb kopierar historiska rader i batchar (strypt för att skydda prod). Använd `INSERT ... ON CONFLICT DO NOTHING` så att det är idempotent och säkert att köra om.
3. **CDC-ikappkörning.** Dubbelskrivning kan missa rader skrivna under påslagningen. **Debezium** som strömmar OLD DB:ns WAL/binlog replayar varje ändring och stänger glappet som backfill inte kan.
4. **Shadow reads.** Läs från NEW parallellt med OLD, **jämför resultat**, och emitta en diff-metrik. Noll diffar över tid = NEW är pålitlig.
5. **Cutover.** Vänd en feature flag så att läsningar (sedan skrivningar) går till NEW. Det är en konfigurationsändring, inte en deploy — omedelbar, och **reversibel genom att vända tillbaka**.

## Intervjuperspektiv

Intervjuaren vill ha **hur du garanterar ingen dataförlust och ingen nedtid**, och om du har en **rollback**. Bra svar nämner dubbelskrivning; utmärkta svar lägger till **CDC för att fånga race-fönstret**, **shadow reads för att verifiera innan du litar**, och en **atomisk, reversibel flag-vändning**. Den klassiska fällan är "backfilla sedan byt" utan verifiering — du upptäcker felmatchningen efter att användare träffat den, utan väg tillbaka.

## Avvägningar & fel

- **Dubbelskrivningskonsistens.** Om NEW-skrivningen misslyckas men OLD lyckas divergerar de. Gör OLD auktoritativ och låt CDC reparera NEW, snarare än att låta användarens request misslyckas.
- **Kostnad & komplexitet.** Att köra två databaser + CDC + backfill är dyrt och driftstungt — motiverat bara för stora, kritiska stores.
- **Schemaändringar** under migration mångdubblar risk; frys schemat till cutover.
- **Backfill-last.** En ostrypt backfill kan mätta prod-I/O och orsaka ett avbrott — motsatsen till målet; batcha och rate-limita.
- **Rollback-fönster.** Fortsätt dubbelskriva (nu NEW→OLD) i dagar efter cutover så att du kan vända tillbaka om en latent bugg dyker upp. Först då avvecklar du OLD.
- **När inte:** en liten DB med ett underhållsfönster behöver inte detta — en 30-minuters `pg_dump`/restore är enklare och säkrare än en CDC-pipeline.

Arkitektur

Så här fungerar det

Intervjuperspektiv

Avvägningar & fel

Relaterade frågor