HA மற்றும் DR-க்கு ஒரு multi-region DB-ஐ எப்படி வடிவமைப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

database-ஐ regions முழுவதும் replicate செய்து தேவைக்கேற்ப உங்கள் topology-ஐத் தேர்ந்தெடுங்கள்: எளிமை மற்றும் strong consistency-க்கு **active-passive** (ஒரு writer, தோல்வியில் ஏற்றுக்கொள்ளும் ஒரு warm standby), அல்லது conflict resolution விலையில் low write latency-க்கு **active-active** (பல writers) — பிறகு durability-ஐ latency-க்கு எதிராக trade செய்ய **sync vs async replication** தேர்ந்தெடுங்கள், மேலும் failover-ஐ இயக்கும் வெளிப்படையான **RPO/RTO** targets-ஐ வரையறுங்கள்.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive**-இல் writes கையாளும் ஒரு primary மற்றும் read மட்டும் செய்யும் standbys உள்ளன; தோல்வியில் நீங்கள் ஒரு standby-ஐ **promote** செய்கிறீர்கள். இது எளிமையானது மற்றும் write conflicts-ஐத் தவிர்க்கிறது, ஆனால் passive capacity idle-ஆக அமர்ந்திருக்கிறது மற்றும் failover-க்கு ஒரு gap உண்டு. **Active-active** ஒவ்வொரு region-ஐயும் local latency-க்காக writes ஏற்க அனுமதிக்கிறது, failover promotion இல்லை — ஆனால் இரண்டு regions ஒரே row-ஐ concurrently edit செய்யலாம், எனவே நீங்கள் conflicts-ஐ resolve செய்ய *வேண்டும்* (last-write-wins, CRDTs, அல்லது app-level merge). பெரும்பாலான குழுக்கள் active-passive-ஆகத் தொடங்குகின்றன; active-active வேறுவழியில்லாத global write latency-க்கு.

## Sync vs async replication

இது மைய durability/latency trade. **Synchronous:** primary commit செய்வதற்கு முன் remote replica ஏற்றுக்கொள்ள காத்திருக்கிறது — **RPO = 0** (failover-இல் data loss இல்லை) ஆனால் ஒவ்வொரு write-ம் cross-region round-trip latency (~பத்துக்கணக்கான ms) செலுத்துகிறது, மேலும் replica அடைய முடியாதெனில் writes நிற்கின்றன. **Asynchronous:** primary local-ஆக commit செய்து பிறகு changes-ஐ அனுப்புகிறது — வேகமான writes, ஆனால் ஒரு region loss கடைசி சில வினாடிகளை இழக்கலாம் (**RPO > 0**). Cross-region sync பெரும்பாலும் மிக மெதுவானது, எனவே பலர் async இயக்கி ஒரு சிறிய RPO-ஐ ஏற்கிறார்கள்.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** நீங்கள் எவ்வளவு data இழக்கலாம் — sync vs async-ஆல் அமைக்கப்படுகிறது.
- **RTO (Recovery Time Objective):** நீங்கள் திரும்பி வர எவ்வளவு நேரம் — தோல்வியைக் கண்டறிந்து promote செய்வது எவ்வளவு வேகம் என்பதால் அமைக்கப்படுகிறது.
- Failover = detect (health checks) → standby-ஐ promote → traffic-ஐ repoint (DNS/global LB). அதை automate செய்யுங்கள், ஆனால் **split-brain**-க்கு (இரண்டு regions-ம் தாங்கள் primary என்று நினைக்கின்றன) ஒரு quorum/fencing token உடன் காவல் செய்யுங்கள்.

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

ஆய்வு: HA/DR என்பது "வெறும் ஒரு replica சேர்" அல்ல, **consistency, latency, மற்றும் data loss இடையேயான ஒரு trade** என்பதை நீங்கள் புரிந்துகொள்கிறீர்களா. நல்லது: ஒரு standby கொண்ட active-passive. சிறந்தது: நீங்கள் RPO/RTO, sync-vs-async தாக்கங்கள், மற்றும் split-brain risk-ஐக் கூறுகிறீர்கள். பொறி: async zero data loss தருகிறது என்று உரிமை கோருவது, அல்லது failover உடனடி மற்றும் lossless என்று கருதுவது.

## சமரசங்களும் தோல்வி முறைகளும்

- **Split-brain:** ஒரு network partition இரண்டு primaries-ஐ promote செய்கிறது → divergent data. quorum, fencing, அல்லது ஒரு witness region பயன்படுத்துங்கள்.
- **Failback கடினம்:** பழைய primary திரும்பிய பிறகு, divergent writes-ஐ reconcile செய்வது manual மற்றும் error-prone.
- **Cost:** உண்மையான multi-region infra-ஐ கிட்டத்தட்ட இரட்டிப்பாக்கி cross-region egress bandwidth bills சேர்க்கிறது.
- **Test செய்யப்படாத failover தோல்வியடைகிறது:** ஒருபோதும் drill செய்யப்படாத DR உண்மையான outage-இல் வேலை செய்யாது — game-days இயக்குங்கள்.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

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

சமரசங்களும் தோல்வி முறைகளும்

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