Sıfır kesinti ile 10TB'lık bir veritabanını migrate edin: plan nedir?

Question

IT Interview Practice · Accepted Answer

**Eski ve yeniye dual-write yapın, geçmişi arka planda backfill edin, kalanı yakalamak için CDC kullanın, shadow read'lerle doğrulayın, sonra okumaları atomik olarak flip'leyin — her adımda bir rollback path ile.** Uygulamayı asla kapatmazsınız; yeni olan kanıtlanabilir şekilde özdeş olana kadar her iki veritabanını paralel çalıştırırsınız, sonra cutover yaparsınız.

## Mimari

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

## Nasıl çalışır

1. **Dual-write.** Uygulama her değişikliği hem OLD hem NEW'e yazar. Yeni satırlar bundan böyle senkron kalır; yalnızca geçmiş eksiktir.
2. **Backfill.** Bir arka plan işi geçmiş satırları batch'ler halinde kopyalar (prod'u korumak için throttle edilir). `INSERT ... ON CONFLICT DO NOTHING` kullanın, böylece idempotent ve yeniden çalıştırmaya güvenlidir.
3. **CDC catch-up.** Dual-write, switch-on sırasında yazılan satırları kaçırabilir. **Debezium**, OLD DB'nin WAL/binlog'unu stream'leyerek her değişikliği replay eder, backfill'in yapamadığı boşluğu kapatır.
4. **Shadow read.** OLD ile paralel olarak NEW'den okuyun, **sonuçları karşılaştırın** ve bir diff metriği yayın. Zaman içinde sıfır diff = NEW güvenilirdir.
5. **Cutover.** Bir feature flag'i flip'leyin, böylece okumalar (sonra yazmalar) NEW'e gider. Bu bir deploy değil, bir config değişikliğidir — anında ve **geri flip'leyerek geri alınabilir**.

## Mülakat perspektifi

Mülakatı yapan kişi, **veri kaybı ve kesinti olmadığını nasıl garanti ettiğinizi** ve bir **rollback**'iniz olup olmadığını ister. İyi cevaplar dual-write'ı belirtir; harika cevaplar **race window'unu yakalamak için CDC**, **güvenmeden önce doğrulamak için shadow read** ve **atomik, geri alınabilir bir flag flip** ekler. Klasik tuzak, doğrulama olmadan "backfill sonra switch"tir — uyuşmazlığı kullanıcılar çarptıktan sonra keşfedersiniz, geri dönüş yolu olmadan.

## Ödünleşimler & hata

- **Dual-write consistency.** NEW yazması başarısız ama OLD başarılı olursa, ayrışırlar. Kullanıcının isteğini başarısız yapmak yerine OLD'u otoriter yapın ve CDC'nin NEW'i onarmasına izin verin.
- **Maliyet & karmaşıklık.** İki veritabanı + CDC + backfill çalıştırmak pahalı ve operasyonel olarak ağırdır — yalnızca büyük, kritik store'lar için haklıdır.
- **Migration sırasında schema değişiklikleri** riski katlar; cutover'a kadar schema'yı dondurun.
- **Backfill yükü.** Throttle edilmemiş bir backfill prod I/O'yu doyurabilir ve bir kesintiye neden olabilir — amacın tersi; batch'leyin ve rate-limit yapın.
- **Rollback window'u.** Cutover'dan sonra günlerce dual-write yapmaya devam edin (şimdi NEW→OLD), böylece latent bir bug ortaya çıkarsa geri flip'leyebilirsiniz. Ancak o zaman OLD'u devre dışı bırakın.
- **Ne zaman yapılmamalı:** bakım penceresi olan küçük bir DB buna ihtiyaç duymaz — 30 dakikalık bir `pg_dump`/restore, bir CDC pipeline'ından daha basit ve güvenlidir.

Mimari

Nasıl çalışır

Mülakat perspektifi

Ödünleşimler & hata

İlgili sorular