Migroni një bazë të dhënash 10TB me zero downtime: cili është plani?

Question

IT Interview Practice · Accepted Answer

**Bëni dual-write te e vjetra dhe e reja, backfill-oni historinë në sfond, përdorni CDC për të kapur pjesën e fundit, verifikoni me shadow reads, pastaj flip-oni leximet në mënyrë atomike — me një rrugë rollback në çdo hap.** Kurrë nuk e ndalni aplikacionin; ekzekutoni të dyja bazat paralelisht derisa e reja të jetë provueshëm identike, pastaj bëni cutover.

## Arkitektura

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

## Si funksionon

1. **Dual-write.** Aplikacioni shkruan çdo ndryshim te të dyja OLD dhe NEW. Rreshtat e rinj mbeten në sync tani e tutje; vetëm historia mungon.
2. **Backfill.** Një job në sfond kopjon rreshtat historikë në batch-e (throttled për të mbrojtur prod). Përdorni `INSERT ... ON CONFLICT DO NOTHING` që të jetë idempotent dhe i sigurt për t'u ri-ekzekutuar.
3. **CDC catch-up.** Dual-write mund të humbë rreshtat e shkruar gjatë ndezjes. **Debezium** që bën stream të WAL/binlog të OLD DB bën replay të çdo ndryshimi, duke mbyllur hendekun që backfill-i nuk mundet.
4. **Shadow reads.** Lexoni nga NEW paralelisht me OLD, **krahasoni rezultatet**, dhe emetoni një diff metric. Zero diffs me kalimin e kohës = NEW është i besueshëm.
5. **Cutover.** Flip-oni një feature flag që leximet (pastaj shkrimet) të shkojnë te NEW. Është një ndryshim konfigurimi, jo një deploy — i menjëhershëm, dhe **i kthyeshëm duke flip-uar mbrapsht**.

## Këndvështrimi i intervistës

Intervistuesi dëshiron **si garantoni asnjë humbje të dhënash dhe asnjë downtime**, dhe nëse keni një **rollback**. Përgjigjet e mira përmendin dual-write; përgjigjet e shkëlqyera shtojnë **CDC për të kapur dritaren e race**, **shadow reads për të verifikuar para se të besoni**, dhe një **flip flag-u atomik e të kthyeshëm**. Kurthi klasik është "backfill pastaj switch" pa verifikim — e zbuloni mospërputhjen pasi përdoruesit e godasin, pa rrugë kthimi.

## Kompromiset & gabimet

- **Konsistenca e dual-write.** Nëse shkrimi NEW dështon por OLD ka sukses, ata divergojnë. Bëjeni OLD autoritativ dhe lëreni CDC të riparojë NEW, në vend që të dështoni request-in e përdoruesit.
- **Kosto & kompleksitet.** Ekzekutimi i dy bazave + CDC + backfill është i shtrenjtë dhe operacionalisht i rëndë — i justifikuar vetëm për store të mëdha e kritike.
- **Ndryshimet e skemës** gjatë migrimit shumëfishojnë rrezikun; ngrini skemën derisa cutover.
- **Ngarkesa e backfill.** Një backfill i pathrottluar mund të ngopë I/O-në e prod dhe të shkaktojë një ndërprerje — e kundërta e qëllimit; batch dhe rate-limit.
- **Dritarja e rollback.** Vazhdoni dual-writing (tani NEW→OLD) për ditë pas cutover që të mund të flip-oni mbrapsht nëse një bug latent shfaqet. Vetëm atëherë çmontoni OLD.
- **Kur jo:** një DB e vogël me një dritare mirëmbajtjeje nuk ka nevojë për këtë — një `pg_dump`/restore 30-minutësh është më i thjeshtë dhe më i sigurt se një pipeline CDC.

Arkitektura

Si funksionon

Këndvështrimi i intervistës

Kompromiset & gabimet

Pyetje të ngjashme