zero downtime के साथ एक 10TB database migrate करें: योजना क्या है?

Question

IT Interview Practice · Accepted Answer

**पुराने और नए दोनों में dual-write करें, background में history backfill करें, tail catch-up के लिए CDC इस्तेमाल करें, shadow reads से verify करें, फिर reads को atomically flip करें — हर step पर एक rollback path के साथ।** आप कभी app down नहीं करते; आप दोनों databases को समानांतर चलाते हैं जब तक नया provably समान न हो, फिर cut over करते हैं।

## आर्किटेक्चर

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

## यह कैसे काम करता है

1. **Dual-write.** app हर change को OLD और NEW दोनों में लिखता है। नई rows अब से sync रहती हैं; केवल history गायब है।
2. **Backfill.** एक background job historical rows को batches में copy करता है (prod की रक्षा के लिए throttled)। `INSERT ... ON CONFLICT DO NOTHING` इस्तेमाल करें ताकि यह idempotent और फिर से चलाने में safe हो।
3. **CDC catch-up.** Dual-write switch-on के दौरान लिखी गई rows छूट सकती है। **Debezium** OLD DB के WAL/binlog को stream करके हर change replay करता है, वह gap भरता है जो backfill नहीं कर सकता।
4. **Shadow reads.** OLD के समानांतर NEW से पढ़ें, **परिणामों की तुलना करें**, और एक diff metric emit करें। समय के साथ शून्य diffs = NEW भरोसेमंद है।
5. **Cutover.** एक feature flag flip करें ताकि reads (फिर writes) NEW पर जाएं। यह एक config बदलाव है, deploy नहीं — तुरंत, और **वापस flip करके reversible**।

## इंटरव्यू का नज़रिया

Interviewer चाहता है **आप कैसे कोई data loss और कोई downtime नहीं गारंटी देते**, और क्या आपके पास एक **rollback** है। अच्छे जवाब dual-write का उल्लेख करते हैं; बढ़िया जवाब **race window पकड़ने के लिए CDC**, **भरोसे से पहले verify करने के लिए shadow reads**, और एक **atomic, reversible flag flip** जोड़ते हैं। क्लासिक जाल है "backfill फिर switch" बिना verification के — आप mismatch तब खोजते हैं जब users उससे टकराते हैं, बिना वापसी के।

## ट्रेड-ऑफ़ और failure

- **Dual-write consistency.** अगर NEW write fail हो पर OLD सफल हो, वे diverge करते हैं। OLD को authoritative बनाएं और CDC को NEW repair करने दें, यूज़र की request fail करने के बजाय।
- **Cost और complexity.** दो databases + CDC + backfill चलाना महंगा और operationally भारी है — केवल बड़े, critical stores के लिए उचित।
- **Schema changes** migration के दौरान जोखिम कई गुना करते हैं; cutover तक schema freeze करें।
- **Backfill load.** एक unthrottled backfill prod I/O को saturate कर एक outage कर सकता है — लक्ष्य के विपरीत; batch और rate-limit करें।
- **Rollback window.** cutover के बाद कुछ दिन dual-writing जारी रखें (अब NEW→OLD) ताकि अगर कोई latent bug उभरे तो आप वापस flip कर सकें। तभी OLD decommission करें।
- **कब नहीं:** एक maintenance window वाले छोटे DB को इसकी ज़रूरत नहीं — एक 30-मिनट `pg_dump`/restore एक CDC pipeline से सरल और सुरक्षित है।

आर्किटेक्चर

यह कैसे काम करता है

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

संबंधित प्रश्न