يوفّر Managed Postgres مستويات مختلفة من التوافر العالي بما يتوافق مع متطلباتك من حيث الاعتمادية والأداء. يمكنك إضافة مثيل احتياطي واحد أو اثنين عند تهيئة قاعدة البيانات، أو تعديل هذا الإعداد لاحقًا من صفحة الإعدادات حسب الحاجة.
مع وجود مثيلين احتياطيين، يتم توفير عقدتَي replica إلى جانب المثيل الأساسي. ويكون كلا المثيلين الاحتياطيين بالحجم نفسه للمثيل الأساسي، ويمكن لأيٍّ منهما تولّي العمل إذا تعطّل المثيل الأساسي.
يستخدم هذا الإعداد النسخ المتماثل المتزامن، حيث ينتظر المثيل الأساسي إقرارًا من مثيل احتياطي واحد على الأقل قبل تأكيد عمليات الكتابة. ويوفّر ذلك ضمانات متانة أقوى من النسخ المتماثل غير المتزامن. ونظرًا إلى أن إقرارًا واحدًا فقط مطلوب (وليس كليهما)، فإن تأثيره في الأداء يكون أقل حدةً مقارنةً بالنسخ المتماثل المتزامن مع مثيل احتياطي واحد.
مع وجود مثيل احتياطي واحد، تُنشأ عقدة نسخة متماثلة إلى جانب العقدة الأساسية لديك. ويكون المثيل الاحتياطي بنفس حجم العقدة الأساسية، ويمكنه تولّي العمل إذا تعطلت العقدة الأساسية.
تُنسخ البيانات إلى المثيل الاحتياطي باستخدام النسخ المتماثل غير المتزامن. وهذا يعني أن عمليات الكتابة تُعتمد على العقدة الأساسية من دون انتظار إقرار من المثيل الاحتياطي. ويضمن النسخ المتماثل غير المتزامن ألا يؤدي التوافر العالي إلى إبطاء عمليات الكتابة بسبب زيادة زمن انتقال الشبكة. ومع ذلك، فهذا يعني أيضًا أن المثيل الاحتياطي قد لا يكون قد تلقّى أحدث المعاملات عند لحظة تعطل العقدة الأساسية. وبالنسبة إلى معظم التطبيقات، فإن هذه الموازنة بين الأداء والمخاطرة المحدودة بفقدان أحدث عمليات الكتابة تستحق ذلك. وإذا كانت متانة عمليات الكتابة ضرورية، فيوصى باختيار مثيلين احتياطيين.
مع هذا الخيار، يتم توفير عقدة أساسية فقط بالحجم الذي اخترته. ولا يتم إنشاء عقدة احتياطية. تظل العقدة الأساسية خاضعة للمراقبة لاكتشاف حالات الفشل، لكن قد تستغرق عملية الاسترداد وقتًا أطول بحسب طبيعة المشكلة، إذ لا توجد نسخة متماثلة جاهزة لتولي المهمة. يُعد هذا الإعداد الأنسب لبيئات التطوير والاختبار أو أعباء العمل غير الحرجة التي يكون فيها بعض التوقف مقبولًا.
مثيلات احتياطية مقابل النسخ المتماثلة للقراءة
لماذا لا تخدم مثيلات احتياطية استعلامات القراءة
-
التنافس مع WAL replay: في أعباء العمل الكثيفة بالكتابة، تتنافس استعلامات القراءة على مثيل احتياطي مع WAL replay على موارد النظام. وقد يؤدي هذا التنافس إلى ارتفاع تأخر النسخ المتماثل، ما يعني أن مثيل احتياطي يتأخر عن الأساسي. وإذا حدث التبديل عند الفشل بينما كان مثيل احتياطي متأخرًا، فلن تتوفر لديه أحدث البيانات، وقد لا يكون جاهزًا لتولّي العمل بسلاسة.
-
التداخل مع VACUUM: يمكن لاستعلامات القراءة طويلة التشغيل على مثيل احتياطي أن تمنع
VACUUM (وAUTOVACUUM) من تنظيف الـ tuples الميتة على الأساسي. ولا يستطيع PostgreSQL إزالة الصفوف التي قد يظل أي استعلام نشط على أي نسخة متماثلة بحاجة إلى الوصول إليها. وقد يؤدي ذلك إلى تضخم الجداول وتراجع الأداء بمرور الوقت.
ومن خلال تخصيص مثيلات احتياطية لعمليات التبديل عند الفشل فقط، يضمن Managed Postgres أنها تظل متزامنة دائمًا وجاهزة لتولّي العمل بأقل قدر ممكن من فقدان البيانات ووقت التعطل. أما لأغراض read scaling، فاستخدم نسخة متماثلة للقراءة بدلًا من ذلك.
تُراقَب جميع مثيلات Managed Postgres باستمرار لرصد الأعطال، سواء كان التوافر العالي مُمكّنًا أم لا. وفي جميع الحالات، يحاول النظام التعافي تلقائيًا من الأعطال.
عند توفّر المثيلات الاحتياطية، تكون عملية التعافي التلقائي أسرع وأكثر سلاسة. وعادةً ما يستعيد النظام عافيته خلال دقائق عبر ترقية مثيل احتياطي إلى مثيل أساسي. أما من دون مثيلات احتياطية، فقد يتطلب التعافي تدخلًا يدويًا، مما يزيد مدة أي انقطاع بشكل كبير. آخر تعديل في ٢٥ يونيو ٢٠٢٦
