.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
حين يتوقف سيرفر التطبيق يمكنك تشغيل نسخة أخرى خلال دقائق. أما حين تتوقف قاعدة البيانات فيتوقف كل شيء معها، والعودة قد تعني استعادة نسخة احتياطية وفقدان ما كُتب بعدها. لهذا يبحث كثير من الفرق عن «التوفر العالي» لـPostgreSQL، ويظهر اسم Patroni بسرعة.
لكن Patroni ليس مجانياً حتى لو كان مفتوح المصدر: ثمنه سيرفرات أكثر، وتعقيد تشغيلي، وأعطال من نوع جديد. في هذا المقال نجيب عن سؤالين عمليين: هل يستحق نظامك هذا التعقيد؟ وإن كان يستحقه، فكم سيرفراً تحتاج فعلاً؟
ما الذي يفعله Patroni؟
PostgreSQL يوفر النسخ المتدفق (Streaming Replication) من سيرفر رئيسي إلى نسخ تابعة، لكنه لا يقرر وحده متى ترقّى نسخة لتصبح رئيسية. هذا القرار هو ما يديره Patroni:
- يراقب كل عقدة ويحتفظ بقفل قيادة في مخزن توافق موزّع مثل etcd.
- إن سقط السيرفر الرئيسي وانتهت مهلة قفله، يرقّي النسخة الأنسب تلقائياً.
- يعيد العقدة القديمة إلى الكتلة كتابعة حين تعود، مع إمكان استعمال pg_rewind.
- يتيح تبديلاً مخططاً أثناء الصيانة بأمر واحد.
أما التطبيق فلا يعرف من هو الرئيسي، ولذلك توضع أمام الكتلة طبقة توجيه مثل HAProxy تسأل واجهة Patroni عن دور كل عقدة وتوجّه الاتصال إلى الرئيسي الحالي.
هل تستحق نظامك؟
ابدأ بسؤالين تجاريين لا تقنيين: كم دقيقة توقف يتحملها العمل؟ وكم دقيقة من البيانات يمكن أن تخسرها؟ يُسميان RTO وRPO. وبعدهما يصبح القرار واضحاً:
| الحالة | الحل المناسب | السبب |
|---|---|---|
| التوقف لساعة مقبول، والبيانات تتغير ببطء | سيرفر واحد + نسخ احتياطي مُجرَّب | أبسط، وكثير من الأنظمة لا تحتاج أكثر |
| التوقف لساعة مؤلم، والتحويل اليدوي مقبول | رئيسي + نسخة تابعة بترقية يدوية | حماية جيدة بلا مكوّنات إضافية |
| التوقف مكلف في أي وقت، ولا أحد يستطيع التدخل فوراً | Patroni بثلاث عقد | تحويل تلقائي بقرار توافق |
| تُمنع خسارة أي معاملة مؤكدة | Patroni مع نسخ متزامن | حماية أعلى، مقابل زمن كتابة أكبر |
سؤال صريح: إن لم يكن في فريقك من يفهم هذه الكتلة ويختبرها، فقد تسبّب توقفاً أكثر مما تمنع. سيرفر واحد سليم مع نسخ احتياطي واستعادة مجرَّبة خير من كتلة لا يعرف أحد كيف يصلحها.
كم سيرفراً تحتاج؟
الجواب الموثوق في أغلب الحالات: ثلاث عقد. والسبب الانقسام: لو انقطع الاتصال بين سيرفرين فقط، لظنّ كل منهما أن الآخر سقط، وقد يقبل الاثنان الكتابة فتتشعّب البيانات. مخزن التوافق يمنع ذلك باشتراط الأغلبية:
| عقد التوافق | الأغلبية المطلوبة | كم عقدة يمكن فقدها |
|---|---|---|
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
يتضح من الجدول أن عقدتين لا تعطيان أي تحمّل، وأن العدد الزوجي لا يضيف شيئاً. لذلك تختار 3، أو 5 إذا أردت تحمّل فقد عقدتين.
لا يلزم أن تحمل العقد الثلاث قاعدة بيانات كاملة. الترتيب الاقتصادي هو سيرفران لـPostgreSQL وعقدة ثالثة صغيرة تشغّل etcd فقط كشاهد. لكن اجعل العقد على عتاد فيزيائي مختلف. ثلاثة أجهزة افتراضية على سيرفر واحد تعطيك شكل التوفر العالي لا حقيقته، لأن تعطل السيرفر يسقطها جميعاً.
هذا مقطع افتراضي مختصر من إعداد عقدة، يوضح الأجزاء الأساسية فقط:
scope: pg-demo
name: db-01
restapi:
listen: 10.0.0.11:8008
connect_address: 10.0.0.11:8008
etcd3:
hosts: 10.0.0.11:2379,10.0.0.12:2379,10.0.0.13:2379
bootstrap:
dcs:
synchronous_mode: true
postgresql:
use_pg_rewind: true
postgresql:
listen: 10.0.0.11:5432
connect_address: 10.0.0.11:5432
data_dir: /var/lib/postgresql/dataوبعد التشغيل، تعرض حالة الكتلة بأمر patronictl -c /etc/patroni.yml list، ويجري التبديل المخطط بأمر patronictl -c /etc/patroni.yml switchover.
المتزامن أم غير المتزامن؟ والنسخ الاحتياطي
في النسخ غير المتزامن يؤكد الرئيسي المعاملة قبل وصولها إلى التابع، فقد تضيع آخر المعاملات عند السقوط. وفي المتزامن ينتظر تأكيد التابع، فتزيد الحماية ويزيد زمن كل كتابة بمقدار الشبكة بين العقدتين. لذلك يجب أن يكون الاتصال بين العقد سريعاً وموثوقاً.
أما النسخ الاحتياطي فلا غنى عنه: التكرار ليس نسخاً احتياطياً. أمر DELETE خاطئ يصل إلى التوابع خلال لحظة. احتفظ بنسخ أساسية وسجلات WAL خارج الكتلة بأداة مثل pgBackRest، لتتمكن من الاستعادة إلى لحظة محددة قبل الخطأ. وجدوِل النسخ الكبيرة فجراً، فهو أدنى حمل في تجربتنا على شبكات العراق.
ابدأ بالعتاد: زمن الشبكة في العراق بين 70 و150ms، أما توليد الصفحة فمن 150ms إلى أكثر من ثانيتين حسب العتاد. المسافة تكلّف عشرات الملّي ثانية والعتاد الضعيف يكلّف آلافاً. وكثير من «مشاكل القاعدة» تحلها الأقراص والفهارس قبل الكتل. اسأل عن المعالج والتخزين لا عن المدينة وحدها، فعتاد مرام هوست يشمل AMD EPYC 9684X بذاكرة L3 سعتها 1152MB، وهي فئة مقصودة للأحمال التي تستفيد من ذاكرة مؤقتة كبيرة.
لمن تناسب هذه الخدمة؟
- منصات يعني توقف قاعدتها توقف إيراد مباشر، كالمدفوعات والحجوزات والطلبات.
- أنظمة SaaS لديها التزامات خدمة تجاه عملائها.
- فرق لديها من يدير الكتلة ويختبرها دورياً.
تجد العقد المناسبة في سيرفرات قواعد البيانات أو السيرفرات المخصصة. أما إن كان نظامك في بدايته فلا تستعجل، وابدأ بسيرفر قوي ونسخ احتياطي سليم.
أخطاء شائعة
- عقدتان فقط: لا أغلبية عند فقد إحداهما، فتفقد ما جئت لأجله.
- كل العقد على عتاد واحد: نقطة فشل واحدة بثلاث نسخ.
- متزامن بعقدتين دون تخطيط: قد تتوقف الكتابة عند غياب التابع، فافهم سلوك الإعداد قبل اعتماده.
- عدم تجربة السقوط: الكتلة التي لم تُختبر بإطفاء الرئيسي عمداً لم تثبت شيئاً.
- إهمال مراقبة تأخر النسخ: تابع متأخر يعني بيانات ناقصة عند الترقية.
- الاعتماد على الترحيل الحي بدل الكتلة: الترحيل الحي في KVM ينقل جهازاً سليماً بانقطاع قصير، إذ سجّل في اختبارنا 423ms لقرص 1GiB، لكنه صيانة مخططة ولا يحميك من تعطل مفاجئ.
أسئلة شائعة
هل يكفي تعديل التطبيق ليتصل بعدة عناوين؟
مكتبة الاتصال الحديثة تستطيع تجربة عدة مضيفين والبحث عن القابل للكتابة، وهذا خيار بسيط لبعض الأنظمة. لكن طبقة توجيه مثل HAProxy تعطيك تحكماً أوضح، ويفضّل أن تكون هي أيضاً بلا نقطة فشل واحدة.
هل أحتاج PgBouncer؟
إن كان تطبيقك يفتح اتصالات كثيرة فهو مفيد، لأن كل اتصال بالقاعدة يستهلك ذاكرة. ويوضع عادة بين التطبيق والقاعدة، ويجب تضمينه في خطة التوفر.
ماذا عن نسخ القراءة؟
يمكن توجيه استعلامات القراءة إلى التوابع لتخفيف الرئيسي، بشرط أن يتحمّل التطبيق تأخراً بسيطاً في البيانات، فبعض الشاشات يجب أن تقرأ من الرئيسي دائماً.
الخطوة التالية
اكتب قيمتي RTO وRPO لعملك أولاً. إن أوصلتاك إلى كتلة، فخطّط لثلاث عقد على عتاد مختلف ونسخ احتياطي خارجها، واختبر السقوط قبل الإطلاق. اطّلع على سيرفرات قواعد البيانات، أو تواصل مع فريق المبيعات لاختيار العقد المناسبة لحملك.
