التوفر العالي (HA) يعني إبقاء قاعدة البيانات متاحة حتى عند حدوث أعطال — من خلال النسخ المتطابقة (standby replicas)، الانتقال التلقائي للفشل (ترقية نسخة متطابقة عندما تفشل الأساسية)، والبنية المناسبة. الهدف: تقليل وقت التوقف وفقدان البيانات، لأن انقطاعات قاعدة البيانات تؤدي إلى توقف التطبيق بأكمله.
الأساس: النسخ المتطابقة + الانتقال التلقائي للفشل
Primary ──(streaming replication)──▶ Standby replica(s)
If the PRIMARY fails:
→ a STANDBY is automatically PROMOTED to become the new primary (FAILOVER)
→ the application reconnects to the new primary → minimal downtime
→ Without HA, a primary failure = total database outage = application down.
تحافظ النسخ المتطابقة على مزامنة النسخ المتطابقة الاحتياطية؛ الانتقال التلقائي للفشل يكتشف فشل النسخة الأساسية وترقي نسخة متطابقة — تحويل انقطاع كامل إلى انقطاع قصير.
أدوات التوفر العالي (أتمتة الانتقال للفشل)
Patroni → the popular HA solution: manages failover, uses a consensus store (etcd/
Consul/ZooKeeper) to coordinate, prevents split-brain
repmgr → replication and failover management
Managed Postgres (AWS RDS/Aurora, Cloud SQL, etc.) → built-in HA with automatic failover
→ These automate detection + promotion, which is hard to do safely by hand.
الانتقال اليدوي بطيء وعرضة للأخطاء، لذا أدوات التوفر العالي (أو الخدمات المُدارة) تأتمتتها بأمان — بما في ذلك منع انقسام الدماغ (وجود نسختين أساسيتين تقبلان الكتابات، مما يفسد البيانات).
توجيه الاتصال
Applications need to find the CURRENT primary after a failover:
→ a load balancer / proxy (HAProxy, PgBouncer) or service discovery routes
WRITES to the current primary and READS to replicas
→ after failover, routing updates to point to the new primary
اعتبارات التوفر العالي الرئيسية
✓ Synchronous replication → no data loss on failover (vs async's small loss window)
✓ Multiple replicas / multiple availability zones → survive zone failures
✓ Avoid SPLIT-BRAIN (two primaries) — consensus/fencing prevents it (critical for safety)
✓ Monitoring + health checks to detect failures quickly
✓ Test failover regularly (like backups, untested failover may not work)
→ Many teams use MANAGED Postgres for built-in, battle-tested HA.
لماذا هذا مهم
التوفر العالي معرفة مهمة لتشغيل أنظمة PostgreSQL الحرجة للإنتاج، لأن انقطاعات قاعدة البيانات تؤدي إلى توقف التطبيق بأكمله (قاعدة البيانات غالباً أكثر تبعية حرجة)، لذا فهم كيفية إبقاء Postgres متاحاً رغم الأعطال هو معرفة مهمة على مستوى كبير للأنظمة الموثوقة.
الأساس — النسخ المتطابقة بالإضافة إلى الانتقال التلقائي للفشل — هو ما يحول فشل قاعدة بيانات أساسية (الذي كان بخلاف ذلك انقطاعاً كاملاً للتطبيق) إلى انقطاع قصير قابل للاسترجاع: النسخ المتطابقة الاحتياطية تبقى متزامنة، وعندما تفشل النسخة الأساسية، يتم ترقية نسخة متطابقة تلقائياً لتولي المسؤولية.
فهم أدوات التوفر العالي (Patroni — الحل الشهير الذي ينسق الانتقال للفشل عبر متجر الإجماع؛ repmgr؛ أو Postgres السحابي المُدار مع التوفر العالي المدمج) مهم لأن أتمتة الانتقال للفشل بأمان صعبة جداً لتنفيذها يدوياً.
معرفة الاعتبارات الرئيسية حرجة: النسخ المتطابقة المتزامنة لعدم فقدان البيانات عند الانتقال للفشل، نسخ متطابقة متعددة عبر مناطق التوفر للبقاء على قيد الحياة عند فشل المنطقة، والأهم تجنب انقسام الدماغ (منع نسختين أساسيتين من قبول الكتابات في نفس الوقت، مما يفسد البيانات — خطر خطير يمنعه الإجماع/الحاجز).
فهم توجيه الاتصال (توجيه التطبيق إلى النسخة الأساسية الحالية بعد الانتقال للفشل، عبر موازنات الحمل/الوكلاء) وأن الانتقال للفشل (مثل النسخ الاحتياطية) يجب أن يكون مُختبراً يكمل المعرفة العملية.
معرفة أن العديد من الفرق تستخدم Postgres المُدار للتوفر العالي المُختبر في المعارك ذات صلة أيضاً.
لأن توفر قاعدة البيانات حرج للأنظمة الإنتاجية (الانقطاع يوقف كل شيء)، وبما أن تحقيقها يتطلب فهم النسخ المتطابقة، والانتقال التلقائي للفشل، ومنع انقسام الدماغ، وتوجيه الاتصال (أو استخدام التوفر العالي المُدار)، فهم التوفر العالي في PostgreSQL هو معرفة مهمة على مستوى كبير لبناء أنظمة موثوقة وجادة — مصدر قلق حرج متكرر لقواعد البيانات الإنتاجية وموضوع يدل على فهم كيفية بناء بنية قاعدة بيانات تتعافى من الأعطال، متوقع للأدوار العليا في قاعدة البيانات/البنية الأساسية.