كيف يعمل التكرار (Replication) في PostgreSQL؟

Question

Accepted Answer

**التكرار (Replication)** ينسخ البيانات من قاعدة البيانات **الأساسية (primary)** إلى خادم أو عدة خوادم **نسخ احتياطية (replica/standby)** — لتحقيق التوفر العالي (failover في حالة فشل الأساسية) وتوسيع القراءة (توزيع استعلامات القراءة). يستخدم PostgreSQL بشكل أساسي **التكرار المباشر (streaming replication)** (physical) بناءً على سجل الكتابة المسبقة (WAL).

## التكرار المباشر (streaming 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
```

الخادم الأساسي يرسل بشكل مستمر **WAL** (سجل الكتابة المسبقة — سجل لكل تغيير) إلى النسخ الاحتياطية، التي تطبقه للبقاء متزامنة. النسخ الاحتياطية هي نسخ للقراءة فقط يمكنها أن تخدم استعلامات القراءة.

## الفوائد: التوفر العالي وتوسيع القراءة

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

## التكرار المتزامن مقابل غير المتزامن

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

## التكرار المنطقي (نموذج مختلف)

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

## التوفر العالي في الممارسة العملية

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

## لماذا يهم هذا

التكرار مهم لبناء نشرات PostgreSQL **عالية التوفر وقابلة للتوسع**، لذا فإن فهمه يمثل معرفة قيمة على مستوى أعلى للعاملين في مجال هندسة قواعد البيانات الإنتاجية.

الفائدتان الأساسيتان حاسمتان للتطبيقات الجادة: **التوفر العالي** (إذا فشل قاعدة البيانات الأساسية، يمكن ترقية نسخة احتياطية لتحل محلها، مما يقلل من فترة التوقف — ضروري للأنظمة التي يجب أن تبقى متاحة) و**توسيع القراءة** (توجيه استعلامات القراءة فقط إلى النسخ الاحتياطية يخفف العبء عن الأساسية، مما يسمح للنظام بمعالجة حركة مرور قراءة أكثر — قيمة لأعباء العمل الثقيلة على القراءة).

فهم **التكرار المباشر** (الأساسي يرسل WAL بشكل مستمر إلى النسخ الاحتياطية التي تبقى متزامنة ويمكنها أن تخدم القراءة) هو الأساس.

معرفة المقايضة بين **المتزامن وغير المتزامن** مهمة: غير المتزامن (الافتراضي — كتابات أسرع لكن نافذة صغيرة من فقدان البيانات المحتمل عند failover) مقابل المتزامن (لا فقدان بيانات لكن كتابات أبطأ) — قرار يؤثر على المتانة مقابل الأداء والموثوقية.

فهم **التكرار المنطقي** (تكرار جداول محددة عبر pub/sub، مفيد للهجرات والنسخ الكاملة والتكرار الجزئي/الانتقائي) يوسع الخيارات.

معرفة أن **أدوات التوفر العالي** (Patroni, repmgr, PostgreSQL السحابية المدارة) تؤتمت failover، وأن التوجيه بين القراءة والكتابة يوجه حركة المرور بشكل صحيح، تمثل معرفة معمارية عملية.

بما أن التوفر العالي والقابلية للتوسع متطلبات أساسية لأنظمة قواعد البيانات الإنتاجية، وبما أن التكرار (مع failover التوفر العالي، توسيع القراءة، مقايضة المتانة sync/async، والتكرار المنطقي للمرونة) هو الآلية الأساسية التي يوفرها PostgreSQL لها، فإن فهم التكرار يمثل معرفة مهمة على مستوى أعلى لتصميم نشرات Postgres موثوقة وقابلة للتوسع — قلق معماري متكرر الصلة للأنظمة الإنتاجية وموضوع يوضح فهماً لتوفر قواعد البيانات والتوسع الذي يتوقع من أدوار senior database/backend.