PostgreSQL میں replication کیسے کام کرتی ہے؟

Question

Accepted Answer

**Replication** ایک **primary** ڈیٹابیس سے ڈیٹا کو ایک یا زیادہ **replica** (standby) سرورز کو کاپی کرتی ہے — high availability (اگر primary ناکام ہو تو failover) اور read scaling (read queries کو تقسیم کریں) کے لیے۔ PostgreSQL بنیادی طور پر **streaming replication** (physical) استعمال کرتا ہے جو write-ahead log (WAL) پر مبنی ہے۔

## Streaming (physical) replication

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

Primary اپنا **WAL** (write-ahead log — ہر تبدیلی کا ریکارڈ) replicas کو stream کرتا ہے، جو اسے متوازی رہنے کے لیے apply کرتے ہیں۔ Replicas read-only کاپیاں ہیں جو read queries کو serve کر سکتی ہیں۔

## فوائد: HA اور read scaling

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Synchronous بمقابلہ asynchronous replication

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Logical replication (ایک مختلف ماڈل)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## عملی طریقے میں high availability

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

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

Replication **انتہائی دستیاب اور scalable** PostgreSQL deployments بنانے کے لیے اہم ہے، اس لیے اسے سمجھنا production database architecture کے لیے senior-level knowledge ہے۔

دونوں بنیادی فوائد سنجیدہ ایپلیکیشنز کے لیے اہم ہیں: **high availability** (اگر primary ڈیٹابیس ناکام ہو تو، ایک replica کو promote کیا جا سکتا ہے تاکہ وہ آگے بڑھے، ڈاؤن ٹائم کو کم کریں — ان سسٹمز کے لیے ضروری جو دستیاب رہنے کے لیے ہیں) اور **read scaling** (read-only queries کو replicas پر route کریں تاکہ primary کو unload کریں، سسٹم کو بہت زیادہ read traffic کو ہینڈل کرنے دیں — read-heavy workloads کے لیے قیمتی)۔

**Streaming replication** کو سمجھنا (primary اپنا WAL replicas کو stream کرتا ہے جو متوازی رہتے ہیں اور reads کو serve کر سکتے ہیں) بنیاد ہے۔

**Synchronous بمقابلہ asynchronous** trade-off کو جاننا اہم ہے: asynchronous (default — تیز writes لیکن failover پر data loss کی ایک چھوٹی سی window) بمقابلہ synchronous (کوئی data loss نہیں لیکن سست writes) — ایک durability-vs-performance فیصلہ جو قابل اعتماری کو متاثر کرتا ہے۔

**Logical replication** کو سمجھنا (مخصوص tables کو pub/sub کے ذریعے replicate کرنا، migrations، cross-version، اور partial/selective replication کے لیے مفید) اختیارات کو وسیع کرتا ہے۔

یہ جاننا کہ **HA tooling** (Patroni, repmgr, managed cloud Postgres) failover کو automate کرتا ہے، اور read/write routing traffic کو مناسب طریقے سے ہدایت دیتا ہے، عملی architectural knowledge ہے۔

چونکہ high availability اور scalability production ڈیٹابیس سسٹمز کے لیے ضروری ضروریات ہیں، اور چونکہ replication (اس کی HA failover، read scaling، sync/async durability trade-off، اور flexibility کے لیے logical replication کے ساتھ) PostgreSQL جو فراہم کرتا ہے وہ بنیادی میکانزم ہے، replication کو سمجھنا reliable، scalable Postgres deployments کو نقشہ بنانے کے لیے senior-level knowledge ہے — production systems کے لیے اکثر متعلقہ تشویش اور ایک ایسا موضوع جو database availability اور scaling کو سمجھنے کا مظاہرہ کرتا ہے جو senior database/backend roles کے لیے متوقع ہے۔