Migrasi database 10TB dengan sifar masa henti: apakah rancangannya?

Question

IT Interview Practice · Accepted Answer

**Dual-write ke lama dan baharu, backfill sejarah di latar belakang, guna CDC untuk mengejar ekor, sahkan dengan shadow read, kemudian tukar bacaan secara atomik — dengan laluan rollback pada setiap langkah.** Anda tidak pernah menutup app; anda menjalankan kedua-dua database secara selari sehingga yang baharu terbukti identikal, kemudian cutover.

## Seni bina

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

## Cara ia berfungsi

1. **Dual-write.** App menulis setiap perubahan ke kedua-dua OLD dan NEW. Baris baharu kekal segerak dari sekarang; hanya sejarah yang hilang.
2. **Backfill.** Sebuah kerja latar belakang menyalin baris sejarah dalam batch (di-throttle untuk melindungi prod). Guna `INSERT ... ON CONFLICT DO NOTHING` supaya ia idempotent dan selamat untuk dijalankan semula.
3. **CDC catch-up.** Dual-write boleh terlepas baris yang ditulis semasa menghidupkan suis. **Debezium** yang mengalirkan WAL/binlog OLD DB me-replay setiap perubahan, menutup jurang yang tidak boleh ditutup oleh backfill.
4. **Shadow read.** Baca dari NEW secara selari dengan OLD, **bandingkan hasil**, dan pancarkan metrik diff. Sifar diff dari masa ke masa = NEW boleh dipercayai.
5. **Cutover.** Tukar sebuah feature flag supaya bacaan (kemudian penulisan) pergi ke NEW. Ia perubahan config, bukan deploy — serta-merta, dan **boleh diterbalikkan dengan menukar kembali**.

## Perspektif temu duga

Penemu duga mahu **bagaimana anda menjamin tiada kehilangan data dan tiada masa henti**, dan sama ada anda mempunyai **rollback**. Jawapan yang baik menyebut dual-write; jawapan yang hebat menambah **CDC untuk menangkap tingkap perlumbaan (race window)**, **shadow read untuk mengesahkan sebelum mempercayai**, dan **penukaran flag atomik yang boleh diterbalikkan**. Perangkap klasik ialah "backfill kemudian tukar" tanpa pengesahan — anda menemui ketidaksepadanan selepas pengguna mengenainya, tanpa jalan kembali.

## Pertukaran & mod kegagalan

- **Konsistensi dual-write.** Jika penulisan NEW gagal tetapi OLD berjaya, ia menyimpang. Jadikan OLD berautoriti dan biarkan CDC membaiki NEW, dan bukannya menggagalkan permintaan pengguna.
- **Kos & kerumitan.** Menjalankan dua database + CDC + backfill adalah mahal dan berat dari segi operasi — hanya wajar untuk store yang besar dan kritikal.
- **Perubahan schema** semasa migrasi mengganda risiko; bekukan schema sehingga cutover.
- **Beban backfill.** Sebuah backfill tanpa throttle boleh menepu I/O prod dan menyebabkan gangguan — bertentangan dengan matlamat; batch dan rate-limit.
- **Tingkap rollback.** Kekalkan dual-write (kini NEW→OLD) selama beberapa hari selepas cutover supaya anda boleh tukar kembali jika pepijat terpendam muncul. Hanya kemudian nyahtauliahkan (decommission) OLD.
- **Bila jangan:** sebuah DB kecil dengan tingkap penyelenggaraan tidak memerlukan ini — sebuah `pg_dump`/restore 30 minit adalah lebih mudah dan lebih selamat daripada pipeline CDC.

Seni bina

Cara ia berfungsi

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan