MongoDB میں replica sets کیسے کام کرتے ہیں؟

Question

Accepted Answer

ایک **replica set** MongoDB سرورز کا ایک گروپ ہے جو ایک جیسا ڈیٹا برقرار رکھتا ہے — **high availability** (خودکار failover) اور **redundancy** فراہم کرتے ہوئے۔ ایک node **primary** ہے (writes کو سنبھالتا ہے)، دوسرے **secondaries** ہیں (primary کے ڈیٹا کو replicate کرتے ہیں اور reads کی تعمیر کر سکتے ہیں)۔ یہ MongoDB کی reliability کے لیے معیاری mechanism ہے۔

## Replica set کی ساخت

```text
PRIMARY (1)   → receives all WRITES; replicates changes to secondaries
SECONDARIES (2+) → copy the primary's data (via the oplog); can serve READS
ARBITER (optional) → votes in elections but holds no data (for odd vote counts)

Write → Primary → replicated to Secondaries (via the operations log "oplog")
```

Primary writes کو سنبھالتا ہے اور انہیں replicate کرتا ہے (via **oplog**، operations کا ایک log) secondaries کو، جو synchronized رہتے ہیں۔ ایک عام set میں resilience کے لیے 3 members ہوتے ہیں۔

## خودکار failover (high availability)

```text
If the PRIMARY fails:
  → the secondaries detect it and hold an ELECTION
  → a secondary is automatically elected as the NEW PRIMARY
  → the application (via the driver) reconnects to the new primary
  → minimal downtime, no manual intervention
→ This automatic failover is the key high-availability benefit.
```

**Automatic failover** اہم قیمت ہے: اگر primary ناکام ہو تو، replica set خود بخود ایک نیا primary elect کرتا ہے — ایک سرور کی ناکامی کو ایک مختصر وقفے میں بدل دیتے ہوئے بجائے ایک مکمل outage کے۔ (ایک طاق تعداد میں voting members tie elections سے بچتے ہیں۔)

## Read scaling اور read preferences

```js
// reads can be directed to secondaries to offload the primary
db.collection.find().readPref("secondaryPreferred");
// read preferences: primary (default), secondary, nearest, etc.
```

Secondaries reads کی تعمیر کر سکتے ہیں (read capacity کو scale کرتے ہوئے)، **read preferences** سے کنٹرول شدہ — اگرچہ secondary reads قدرے پرانے ہو سکتے ہیں (asynchronous replication)۔

## Write concern (durability)

```js
// write concern: how many nodes must acknowledge a write before it's confirmed
db.collection.insertOne(doc, { writeConcern: { w: "majority" } });
// w: 1 (primary only — fast, less safe) vs w: "majority" (safer — survives failover)
```

**Write concern** durability کو کنٹرول کرتا ہے: `w: "majority"` ایک اکثریت کی nodes کی تسلیم کے لیے انتظار کرتا ہے (زیادہ محفوظ — primary failure کے بغیر data loss کے بچتا ہے) بمقابلہ `w: 1` (تیز لیکن ایک write failover پر کھو سکتا ہے)۔

## یہ کیوں اہم ہے

Replica sets MongoDB کو production میں قابل اعتماد طریقے سے چلانے کے لیے بنیادی ہیں، اس لیے ان کو سمجھنا production MongoDB deployments کے لیے اہم senior-level علم ہے۔

بنیادی قیمت **automatic failover کے ذریعے high availability** ہے: ایک replica set (سرورز کا ایک گروپ جو ایک جیسا ڈیٹا برقرار رکھتے ہیں، ایک primary writes کو سنبھالتے ہوئے اور secondaries replicate کرتے ہوئے) خود بخود ایک نیا primary elect کرتا ہے اگر موجودہ fail ہو — ایک سرور کی ناکامی کو ایک مختصر وقفے میں بدل دیتے ہوئے مکمل outage کی بجائے، جو ان نظاموں کے لیے ضروری ہے جو دستیاب رہنے چاہئیں (اور transactions اور بہت سی production features کے لیے ضروری ہے)۔

Sاخت (primary، secondaries، optional arbiter، replication کے لیے oplog) اور **election/failover** mechanism کو سمجھنا بنیادی ہے۔

یہ جاننا کہ secondaries **reads** کی تعمیر کر سکتے ہیں (read capacity کو scale کرتے ہوئے **read preferences** کے ذریعے، asynchronous replication سے ممکنہ تھوڑی سی staleness کی وارننگ کے ساتھ) کارکردگی کے لیے قابل قدر ہے۔

خاص طور پر اہم **write concern** کو سمجھنا ہے — durability کنٹرول جہاں `w: "majority"` اس بات کو یقینی بناتا ہے کہ ایک write nodes کی اکثریت سے تسلیم ہے (تو یہ primary failover کے بغیر data loss کے بچتا ہے — اہم ڈیٹا کے لیے اہم) بمقابلہ `w: 1` (تیز لیکن failover پر پر خطرناک) — ایک اہم reliability/performance trade-off۔

چونکہ high availability اور durability production databases کے لیے ضروری ہیں، اور چونکہ replica sets (automatic failover کے ساتھ، secondaries کے ذریعے read scaling، اور durability کے لیے write concern) MongoDB کی ان کے لیے بنیادی mechanism ہیں، replica sets کو سمجھنا — ساخت، automatic failover، read preferences، اور خاص طور پر write concern — production میں MongoDB کو قابل اعتماد طریقے سے deploy کرنے کے لیے اہم senior-level علم ہے، ایک بار بار اہم تشویش اور ایک موضوع جو MongoDB کی high-availability اور durability model کی سمجھ کو ظاہر کرتا ہے جو database کے ساتھ کام کرنے والے senior roles کے لیے متوقع ہے۔