كيف تنقل قاعدة البيانات من Server واحد إلى High Availability؟

طالما كان مشروعك صغيرًا، خادم قاعدة بيانات واحد يكفي ويريح. لكن حين يكبر — متجر إلكتروني في موسم الذروة، نظام ERP تعتمد عليه الشركة يوميًّا، منصّة SaaS يدفع عملاؤها مقابل التوافر — يصبح هذا الخادم الواحد نقطة الفشل الوحيدة (Single Point of Failure): لحظة سقوطه يتوقّف كل شيء، وربما تفقد بيانات. الحلّ هو الانتقال إلى Database High Availability (التوافر العالي لقاعدة البيانات). في هذا الدليل نشرح كيف تنقل قاعدتك من خادم واحد إلى بنية عالية التوافر خطوةً بخطوة — Primary/Replica، وFailover، وBackups، وProxy، ومعالجة Replication Lag — مع إثبات حقيقي أعددناه فعليًّا على خادم مرام.

لماذا الخادم الواحد خطر على مشروعك؟

خادم قاعدة البيانات الواحد يعني أن كل بيضك في سلّة واحدة. أي عطل — عتاد، قرص، انقطاع كهرباء، خطأ تحديث — يوقف الخدمة بالكامل حتى تُصلحه أو تستعيد من نسخة احتياطية (وهو ما قد يستغرق ساعات). لمشاريع SaaS وERP والمتاجر الكبيرة، هذا التوقّف يترجم مباشرةً إلى خسائر مالية وفقدان ثقة العملاء.

• توقّف كامل: سقوط الخادم = سقوط التطبيق كلّه، لا قراءة ولا كتابة.
• خطر فقدان البيانات: إن تلف القرص قبل آخر نسخة احتياطية، تضيع المعاملات بينهما.
• استعادة بطيئة: استرجاع قاعدة كبيرة من نسخة احتياطية قد يستغرق ساعات من التوقّف.
• لا مجال للصيانة: أي ترقية أو صيانة تتطلّب إيقاف الخدمة.

التوافر العالي يعالج هذا كلّه بمبدأ بسيط: لا نقطة فشل واحدة. دائمًا هناك عقدة أخرى جاهزة تحلّ محلّ أي عقدة تسقط.

ما هو Database High Availability؟

Database High Availability يعني تصميم بنية قاعدة البيانات بحيث تستمرّ الخدمة رغم أعطال العتاد أو البرمجيات. جوهره تشغيل أكثر من نسخة من قاعدة بياناتك على خوادم منفصلة، مع مزامنة مستمرّة بينها، وآلية تحوّل تلقائي عند العطل. الانتقال إليه ليس قفزةً واحدة بل رحلة تدريجية:

تبدأ من خادم واحد (مقبول للبداية)، ثمّ تضيف Replica لتوزيع القراءة وتوفير نسخة حيّة، ثمّ Failover + Proxy للتحوّل التلقائي، وأخيرًا Backups/PITR للحماية الكاملة. أضِف كل طبقة حسب حساسية مشروعك للتوقّف — لا داعي للقفز إلى أقصى تعقيد من اليوم الأول.

المفاهيم الستّة التي تحكم التوافر

قبل البناء، افهم المصطلحات الستّة التي ستتكرّر في كل قرار — كلٌّ يحلّ جزءًا من معادلة «لا توقّف ولا فقدان بيانات»:

• Primary / Replica: عقدة تقبل الكتابة، وواحدة أو أكثر تخدم القراءة وتبقى جاهزة.
• Streaming Replication: نسخ تغييرات Primary (سجلّ WAL) إلى النُّسخ لحظيًّا.
• Replication Lag: التأخّر بين كتابة Primary وظهورها في Replica.
• Failover: ترقية Replica إلى Primary عند سقوط الأصلي.
• Proxy / Router: يوجّه الكتابة والقراءة تلقائيًّا بلا تغيير كود التطبيق.
• Backups ≠ Replica: النسخة الحيّة ليست نسخة احتياطية — تحتاج نسخًا منفصلة مع PITR.

Primary وReplica: تقسيم الأدوار

أساس Database High Availability هو نمط Primary/Replica. عقدة واحدة (Primary) تقبل كل عمليات الكتابة، وعقدة أو أكثر (Replicas) تنسخ بياناتها منها باستمرار وتخدم عمليات القراءة. هذا يحقّق هدفين معًا: توزيع الحمل (القراءات الكثيرة تذهب للنُّسخ)، والجاهزية (لو سقط Primary، نسخة محدّثة جاهزة للترقية).

في PostgreSQL يتمّ هذا عبر Streaming Replication: يبثّ Primary سجلّ التغييرات (WAL) إلى النُّسخ فور حدوثها. إعداد نسخة فعليًّا أبسط ممّا يبدو:

# على الـReplica: أخذ نسخة كاملة من Primary ثمّ بدء البثّ
pg_basebackup -h primary-host -U repl -D /var/lib/postgresql/replica -R -Xs -P
# ثمّ تشغيلها في وضع standby فتلحق Primary تلقائيًا وتبقى محدّثة

ملاحظة: النسخ قد يكون متزامنًا (synchronous) — لا تُؤكَّد الكتابة إلا بعد وصولها للنسخة (أمان أعلى، بطء بسيط) — أو غير متزامن (asynchronous) — أسرع لكن مع احتمال تأخّر بسيط. الأغلبية تبدأ بغير المتزامن.

Replication Lag: التحدّي الخفي

أهمّ ما يُغفل في التوافر العالي هو Replication Lag: الفارق الزمني بين كتابة بيانات على Primary وظهورها على Replica. عادةً أجزاء من الثانية، لكن تحت الحمل الشديد قد يكبر. خطره أنك إن قرأت فورًا من Replica بعد كتابة على Primary، قد تحصل على بيانات قديمة (مثلًا: مستخدم يحدّث ملفه ثمّ يراه غير محدّث).

• راقب الـLag دائمًا: عبر pg_stat_replication في PostgreSQL أو SHOW REPLICA STATUS في MySQL.
• للقراءات الحسّاسة زمنيًّا: اقرأ من Primary مباشرةً (read-your-writes) بدل Replica.
• للقراءات العامّة: Replica ممتازة — تأخّر أجزاء الثانية غير محسوس.
• قلّل الـLag: بشبكة سريعة بين العقد، وقرص Enterprise NVMe سريع، وموارد كافية على النسخة.

النقطة الأخيرة مهمّة: الـReplica البطيئة تتأخّر أكثر. كما شرحنا في لماذا تصبح قاعدة البيانات أبطأ، سرعة القرص والـI/O تحدّد قدرة النسخة على اللحاق بـPrimary.

Failover: ماذا يحدث عند العطل؟

Failover هو قلب التوافر العالي: حين يسقط Primary، تُرقّى إحدى النُّسخ لتصبح Primary الجديد فتستمرّ الكتابة. يمكن أن يكون:

• يدويًّا: تُصدر أمر ترقية بنفسك (pg_ctl promote) — مقبول لمشاريع تحتمل دقائق توقّف.
• تلقائيًّا: أداة تراقب Primary وترقّي نسخة تلقائيًّا خلال ثوانٍ عند العطل — عبر Patroni أو repmgr أو Orchestrator.

التحوّل التلقائي هو ما يحقّق «شبه صفر توقّف»، لكنّه يتطلّب ضبطًا دقيقًا لتجنّب split-brain (ترقية نسختين معًا). ابدأ بالترقية اليدوية المفهومة، ثمّ أتمتها حين تنضج بنيتك.

💡 نصيحة: بعد أي Failover، تذكّر أن Primary القديم حين يعود يجب أن ينضمّ كـReplica جديدة (لا كـPrimary ثانٍ) — وإلا وقع تعارض. أدوات مثل Patroni تدير هذا تلقائيًّا.

Proxy: توجيه الكتابة والقراءة

مع وجود Primary وعدّة Replicas، كيف يعرف تطبيقك أين يرسل كل استعلام؟ الحلّ الأنظف طبقة Proxy / Connection Router بين التطبيق وقواعد البيانات: توجّه الكتابة (INSERT/UPDATE) إلى Primary والقراءة (SELECT) إلى Replicas تلقائيًّا — وأثناء Failover تعيد التوجيه للعقدة الجديدة بلا تغيير في كود التطبيق.

• PgBouncer: تجميع اتصالات PostgreSQL (connection pooling) خفيف وأساسي.
• HAProxy: موازِن أحمال عام يوزّع على العقد ويكتشف الصحّية منها.
• ProxySQL: لـMySQL، يفصل القراءة عن الكتابة ويوزّع تلقائيًّا.

هذا الفصل بين الكتابة والقراءة هو نفس المبدأ الذي يجعل Redis كطبقة حالة مشتركة فعّالًا — توجيه كل عملية إلى المكان الأنسب لها.

Backups ليست Replica

خطأ خطير شائع: الاعتقاد أن وجود Replica يغني عن النسخ الاحتياطي. الـReplica ليست نسخة احتياطية! لأنها تنسخ كل ما يحدث على Primary فورًا — بما فيه الأخطاء: لو حذف أحدهم جدولًا بالخطأ (DROP TABLE)، يُنسخ الحذف إلى كل النُّسخ في اللحظة نفسها.

• نسخ احتياطي دوري: نسخ كاملة منتظمة تُخزَّن بعيدًا عن خوادم الإنتاج.
• Point-in-Time Recovery (PITR): بحفظ سجلّ WAL، تستطيع الاستعادة لأي لحظة زمنية — مثلًا «قبل دقيقة من الحذف الخاطئ».
• اختبر الاستعادة: نسخة احتياطية لم تُختبَر استعادتها = لا نسخة. جرّب الاستعادة دوريًّا.
• خزّنها بعيدًا: على تخزين منفصل أو Object Storage، لا على نفس الخادم.

⚠ تحذير: الـReplica تحميك من عطل العتاد؛ الـBackup يحميك من الخطأ البشري والفساد المنطقي. تحتاج الاثنين معًا — لا أحدهما بديلًا عن الآخر.

إثبات Database High Availability حقيقي على خادم مرام

لأن النظرية لا تكفي، أعددنا بنية Primary/Replica فعلية على أحد خوادم مرام (PostgreSQL 16.15، Intel Xeon): خادم Primary على المنفذ 5432، وReplica عبر Streaming Replication على 5433، ثمّ اختبرنا النسخ والتأخّر والـFailover فعليًّا:

• النسخ اللحظي: كتبنا القيمة 999.99 على Primary، فقرأتها Replica فورًا — والعدّادان متطابقان (1001 = 1001).
• التأخّر تحت الحمل: دفعنا 50,000 صفّ دفعةً واحدة، فكان أقصى Replication Lag نحو 75 مللي ثانية فقط، ثمّ لحقت النسخة تمامًا (51,001 = 51,001).
• Failover: رقّينا الـReplica إلى Primary (تحوّل pg_is_in_recovery من t إلى f)، فقبلت الكتابة فورًا وصار العدّاد 51,002 — دون فقدان صفٍّ واحد.

🤝 من واقع مرام: هذه أرقام مقيسة فعليًّا على عتاد مرام (PostgreSQL 16.15، Intel Xeon) — لا أرقام مفترضة. الأهمّ من الأرقام هو المبدأ الذي أثبتناه: البيانات المكتوبة على Primary وصلت النسخة خلال أجزاء الثانية، والنسخة تحوّلت إلى Primary عاملة فورًا عند الحاجة. هذا بالضبط ما يمنع التوقّف: أي عقدة تسقط، وأخرى جاهزة تحلّ محلّها بلا فقدان بيانات.

خارطة الانتقال العملية

لتنقل قاعدتك من خادم واحد إلى High Availability بأمان، اتّبع هذا الترتيب:

1. ثبّت النسخ الاحتياطي أولًا: نسخ دورية + WAL/PITR قبل أي شيء — هذا خطّ دفاعك الأخير.
2. أضِف Replica واحدة: عبر Streaming Replication، ووجّه إليها القراءات الثقيلة.
3. راقب Replication Lag: تأكّد أنه منخفض ومستقرّ تحت حملك الحقيقي.
4. أدخِل Proxy: لفصل الكتابة عن القراءة بلا تعديل كود التطبيق.
5. جهّز Failover: ابدأ يدويًّا، ثمّ أتمته بأداة (Patroni/repmgr) حين تنضج.
6. اختبر العطل: أسقِط Primary عمدًا في بيئة اختبار وتأكّد أن التحوّل يعمل — قبل أن يحدث في الإنتاج.

لبناء الطبقات المحيطة (خوادم تطبيق عديمة الحالة، وموازنة أحمال)، راجع متى تبدأ Horizontal Scaling. وللمراجع الرسمية: توافر PostgreSQL العالي وPatroni ونسخ MySQL وHAProxy.

الخلاصة

الانتقال إلى Database High Availability ليس ترفًا لمشاريع SaaS وERP والمتاجر الكبيرة، بل ضرورة تحمي إيرادك وسمعتك. المبدأ واحد: لا نقطة فشل واحدة. ابنِه تدريجيًّا — نسخ احتياطي، فـReplica، فـProxy، فـFailover — وراقب Replication Lag دائمًا. وكما أثبتنا بأرقام حقيقية على خادم مرام، النسخ يتمّ خلال أجزاء الثانية والـFailover يرقّي النسخة فورًا بلا فقدان بيانات. النتيجة: قاعدة بيانات تبقى صامدة مهما سقطت عقدة.