zero downtime உடன் ஒரு 10TB database-ஐ migrate செய்யவும்: திட்டம் என்ன?

Question

IT Interview Practice · Accepted Answer

**பழையது மற்றும் புதியதற்கு dual-write செய்யுங்கள், பின்னணியில் history-ஐ backfill செய்யுங்கள், tail-ஐ catch up செய்ய CDC பயன்படுத்துங்கள், shadow reads உடன் verify செய்யுங்கள், பிறகு reads-ஐ atomically flip செய்யுங்கள் — ஒவ்வொரு படியிலும் ஒரு rollback path உடன்.** நீங்கள் ஒருபோதும் app-ஐ கீழே இறக்குவதில்லை; புதியது நிரூபிக்கத்தக்க அளவில் identical ஆகும் வரை இரண்டு databases-ஐயும் parallel-ஆக இயக்கி, பிறகு 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 ஒவ்வொரு மாற்றத்தையும் OLD மற்றும் NEW இரண்டிற்கும் எழுதுகிறது. புதிய rows இப்போதிலிருந்து sync-இல் இருக்கின்றன; history மட்டுமே காணவில்லை.
2. **Backfill.** ஒரு பின்னணி job historical rows-ஐ batches-இல் copy செய்கிறது (prod-ஐப் பாதுகாக்க throttled). `INSERT ... ON CONFLICT DO NOTHING` பயன்படுத்துங்கள், இதனால் அது idempotent மற்றும் மீண்டும் இயக்க safe.
3. **CDC catch-up.** Dual-write switch-on-இன்போது எழுதப்பட்ட rows-ஐ தவறவிடலாம். OLD DB-இன் WAL/binlog-ஐ streaming செய்யும் **Debezium** ஒவ்வொரு மாற்றத்தையும் replay செய்து, backfill செய்ய முடியாத gap-ஐ மூடுகிறது.
4. **Shadow reads.** OLD-உடன் parallel-ஆக NEW-இலிருந்து படித்து, **முடிவுகளை ஒப்பிட்டு**, ஒரு diff metric emit செய்யுங்கள். காலப்போக்கில் zero diffs = NEW நம்பகமானது.
5. **Cutover.** ஒரு feature flag-ஐ flip செய்யுங்கள், இதனால் reads (பிறகு writes) NEW-க்குச் செல்கின்றன. இது ஒரு config மாற்றம், deploy அல்ல — உடனடி, மேலும் **flip back செய்வதன் மூலம் reversible**.

## நேர்காணல் கண்ணோட்டம்

நேர்காணல் செய்பவர் **data loss இல்லை மற்றும் downtime இல்லை என்பதை எப்படி உறுதி செய்கிறீர்கள்** என்பதையும், உங்களிடம் ஒரு **rollback** உள்ளதா என்பதையும் விரும்புகிறார். நல்ல பதில்கள் dual-write குறிப்பிடுகின்றன; சிறந்த பதில்கள் **race window-ஐப் பிடிக்க CDC**, **நம்புவதற்கு முன் verify செய்ய shadow reads**, மற்றும் ஒரு **atomic, reversible flag flip** சேர்க்கின்றன. classic பொறி "backfill பிறகு switch" verification இல்லாமல் — பயனர்கள் அதை அடைந்த பிறகு mismatch-ஐக் கண்டுபிடிக்கிறீர்கள், திரும்பச் செல்ல வழியில்லாமல்.

## சமரசங்களும் பிழைகளும்

- **Dual-write consistency.** NEW write தோல்வியுற்று OLD வெற்றிபெற்றால், அவை diverge ஆகின்றன. பயனரின் request-ஐ தோல்வியுற வைப்பதற்குப் பதிலாக OLD-ஐ authoritative ஆக்கி CDC-ஐ NEW-ஐ repair செய்ய விடுங்கள்.
- **Cost & complexity.** இரண்டு databases + CDC + backfill இயக்குவது விலையுயர்ந்தது மற்றும் operationally கனமானது — பெரிய, critical stores-க்கு மட்டுமே நியாயமானது.
- **Schema changes** migration-இன்போது risk-ஐ பெருக்குகின்றன; cutover வரை schema-ஐ freeze செய்யுங்கள்.
- **Backfill load.** throttle செய்யப்படாத backfill prod I/O-ஐ saturate செய்து ஒரு outage ஏற்படுத்தலாம் — இலக்கின் எதிர்மறை; batch மற்றும் rate-limit செய்யுங்கள்.
- **Rollback window.** cutover-க்குப் பிறகு நாட்களுக்கு dual-writing (இப்போது NEW→OLD) தொடருங்கள், இதனால் ஒரு latent bug வெளிவந்தால் flip back செய்யலாம். அப்போது மட்டுமே OLD-ஐ decommission செய்யுங்கள்.
- **எப்போது இல்லை:** maintenance window கொண்ட ஒரு சிறிய DB-க்கு இது தேவையில்லை — ஒரு 30-நிமிட `pg_dump`/restore ஒரு CDC pipeline-ஐ விட எளிமையானது மற்றும் பாதுகாப்பானது.

கட்டமைப்பு

எப்படி வேலை செய்கிறது

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் பிழைகளும்

தொடர்புடைய கேள்விகள்