قابلية الوصول العالية (الموثوقية) في قاعدة بيانات Azure ل PostgreSQL - الخادم المرن
ينطبق على: 
قاعدة بيانات Azure ل PostgreSQL - خادم مرن
توضح هذه المقالة قابلية الوصول العالية في قاعدة بيانات Azure ل PostgreSQL - الخادم المرن، والتي تتضمن مناطق التوفر والاسترداد عبر المناطق واستمرارية الأعمال. للحصول على نظرة عامة أكثر تفصيلا على الموثوقية في Azure، راجع موثوقية Azure.
Azure Database for PostgreSQL - يوفر الخادم المرن دعما عالي التوفر من خلال توفير النسخ المتماثلة الأساسية والاستعدادية المنفصلة فعليا، إما داخل نفس منطقة التوفر (المنطقة) أو عبر مناطق التوفر (المنطقة المكررة). تم تصميم نموذج التوفر العالي هذا لضمان عدم فقدان البيانات الملتزم بها أبدا في حالة الفشل. تم تصميم النموذج أيضا بحيث لا تصبح قاعدة البيانات نقطة فشل واحدة في بنية البرامج الخاصة بك. لمزيد من المعلومات حول التوفر العالي ودعم منطقة التوفر، راجع دعم منطقة التوفر.
دعم منطقة القابلية للوصول
مناطق توفر Azure هي ثلاث مجموعات منفصلة فعليا على الأقل من مراكز البيانات داخل كل منطقة Azure. مراكز البيانات داخل كل منطقة مجهزة ببنية أساسية مستقلة للطاقة والتبريد والشبكات. في حالة فشل المنطقة المحلية، يتم تصميم مناطق التوفر بحيث إذا تأثرت المنطقة الواحدة، فإن الخدمات الإقليمية والسعة والتوافر العالي تدعمها المنطقتين المتبقيتين.
يمكن أن تتراوح حالات الفشل من فشل البرامج والأجهزة إلى الأحداث مثل الزلازل والفيضانات والحرائق. يتم تحقيق التسامح مع الفشل مع التكرار والعزلة المنطقية لخدمات Azure. لمزيد من المعلومات التفصيلية حول مناطق التوفر في Azure، راجع المناطق ومناطق التوفر.
تم تصميم الخدمات الممكنة لمناطق توفر Azure لتوفير المستوى الصحيح من الموثوقية والمرونة. يمكن تكوينها بطريقتين. يمكن أن تكون إما زائدة عن الحاجة للمنطقة، مع النسخ المتماثل التلقائي عبر المناطق، أو منطقة، مع تثبيت المثيلات في منطقة معينة. يمكنك أيضا الجمع بين هذه الأساليب. لمزيد من المعلومات حول البنية المناطقية مقابل البنية الزائدة عن الحاجة للمنطقة، راجع توصيات لاستخدام مناطق التوفر والمناطق.
قاعدة بيانات Azure ل PostgreSQL - يدعم الخادم المرن كلا من النماذج المتكررة في المنطقة والنماذج المناطقية لتكوينات قابلية الوصول العالية. يتيح كل من تكوينات قابلية الوصول العالية إمكانية تجاوز الفشل التلقائي مع عدم فقدان البيانات أثناء كل من الأحداث المخطط لها وغير المخطط لها.
المنطقة زائدة عن الحاجة. تنشر قابلية الوصول العالية المكررة للمنطقة نسخة متماثلة احتياطية في منطقة مختلفة مع إمكانية تجاوز الفشل التلقائي. يوفر التكرار في المنطقة أعلى مستوى من التوفر، ولكنه يتطلب منك تكوين تكرار التطبيق عبر المناطق. لهذا السبب، اختر تكرار المنطقة عندما تريد الحماية من حالات فشل مستوى منطقة التوفر وعندما يكون زمن الانتقال عبر مناطق التوفر مقبولا.
يمكنك اختيار المنطقة ومناطق التوفر لكل من الخوادم الأساسية والخوادم الاحتياطية. يتم توفير خادم النسخة المتماثلة الاحتياطية في منطقة التوفر المختارة في نفس المنطقة مع حساب وتخزين وتكوين شبكة مماثلة كخادم أساسي. يتم تخزين ملفات البيانات وملفات سجل المعاملات (سجلات الكتابة المسبقة، a.k.a WAL) على التخزين الزائد محليا (LRS) داخل كل منطقة توفر، وتخزين ثلاث نسخ بيانات تلقائيا. يوفر التكوين المتكرر للمنطقة عزلا ماديا للمكدس بأكمله بين الخوادم الأساسية وخوادم الاستعداد.
منطقة. اختر توزيع نطاقي عندما تريد تحقيق أعلى مستوى من التوفر داخل منطقة توفر واحدة، ولكن مع أقل زمن انتقال للشبكة. يمكنك اختيار المنطقة ومنطقة التوفر لنشر كل من خادم قاعدة البيانات الأساسي. يتم توفير خادم النسخة المتماثلة الاحتياطية وإدارتها تلقائيا في نفس منطقة التوفر - مع حساب وتخزين وتكوين شبكة مماثلة - كخادم أساسي. يحمي التكوين النطاقي قواعد البيانات الخاصة بك من حالات الفشل على مستوى العقدة ويساعد أيضا في تقليل وقت تعطل التطبيق أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها. يتم نسخ البيانات من الخادم الأساسي إلى النسخة المتماثلة الاحتياطية في وضع متزامن. في حال حدوث أي تعطيل للخادم الأساسي، يتم فشل الخادم تلقائياً إلى النسخة المتماثلة الاحتياطية.
إشعار
يتصرف كل من نماذج التوزيع المناطقية ونماذج التوزيع المتكررة في المنطقة بنفس الطريقة من الناحية المعمارية. تنطبق المناقشات المختلفة في الأقسام التالية على كليهما ما لم يتم استدعاؤها بخلاف ذلك.
المتطلبات الأساسية
تكرار المنطقة:
يتوفر خيار تكرار المنطقة فقط في المناطق التي تدعم مناطق التوفر.
التكرار في المنطقة غير مدعوم ل:
- قاعدة بيانات Azure ل PostgreSQL - SKU لخادم واحد.
- طبقة الحوسبة القابلة للاندفاع.
- المناطق التي تتوفر فيها منطقة واحدة.
نطاقي:
- يتوفر خيار التوزيع النطاقي في جميع مناطق Azure حيث يمكنك نشر Flexible Server.
ميزات قابلية الوصول العالية
يتم نشر نسخة متماثلة احتياطية في نفس تكوين الجهاز الظاهري - بما في ذلك vCores والتخزين وإعدادات الشبكة - كخادم أساسي.
يمكنك إضافة دعم منطقة التوفر لخادم قاعدة بيانات موجود.
يمكنك إزالة النسخة المتماثلة الاحتياطية عن طريق تعطيل قابلية الوصول العالية.
يمكنك اختيار مناطق التوفر لخوادم قاعدة البيانات الأساسية والاستعدادية لتوفر المنطقة المكرر.
يتم تنفيذ عمليات مثل الإيقاف والبدء وإعادة التشغيل على كل من خوادم قاعدة البيانات الأساسية وخوادم قاعدة البيانات الاحتياطية في نفس الوقت.
في نماذج المنطقة المكررة والمنطقية، يتم إجراء النسخ الاحتياطية التلقائية بشكل دوري من خادم قاعدة البيانات الأساسي. في الوقت نفسه، يتم أرشفة سجلات المعاملات باستمرار في تخزين النسخ الاحتياطي من النسخة المتماثلة الاحتياطية. إذا كانت المنطقة تدعم مناطق التوفر، يتم تخزين بيانات النسخ الاحتياطي على التخزين المتكرر للمنطقة (ZRS). في المناطق التي لا تدعم مناطق التوفر، يتم تخزين بيانات النسخ الاحتياطي على التخزين المحلي المكرر (LRS).
يتصل العملاء دائما باسم المضيف النهائي لخادم قاعدة البيانات الأساسي.
يتم أيضا تطبيق أي تغييرات على معلمات الخادم على النسخة المتماثلة الاحتياطية.
القدرة على إعادة تشغيل الخادم لالتقاط أي تغييرات معلمة خادم ثابت.
تحدث أنشطة الصيانة الدورية مثل ترقيات الإصدار الثانوي في وضع الاستعداد أولا، ولتقليل وقت التعطل، يتم ترقية الاستعداد إلى المستوى الأساسي بحيث يمكن الاحتفاظ بأحمال العمل، بينما يتم تطبيق مهام الصيانة على العقدة المتبقية.
قيود قابلية الوصول العالية
نظرا للنسخ المتماثل المتزامن إلى خادم الاستعداد، خاصة مع تكوين المنطقة المكررة، يمكن أن تواجه التطبيقات زمن انتقال مرتفع للكتابة والالتزام.
لا يمكن استخدام النسخة المتماثلة الاحتياطية للاستعلامات المقروءة.
اعتمادا على حمل العمل والنشاط على الخادم الأساسي، قد تستغرق عملية تجاوز الفشل أكثر من 120 ثانية بسبب الاسترداد المتضمنة في النسخة المتماثلة الاحتياطية قبل أن يمكن ترقيتها.
عادة ما يسترد خادم الاستعداد ملفات WAL بمعدل 40 ميغابايت/ثانية. إذا تجاوز حمل العمل هذا الحد، يمكنك أن تواجه وقتا ممتدا لإكمال الاسترداد إما أثناء تجاوز الفشل أو بعد إنشاء وضع الاستعداد الجديد.
يؤدي التكوين لمناطق التوفر إلى بعض زمن الانتقال للكتابة والتثبيت، في حين أنه لا ينتج أي تأثير على قراءة الاستعلامات. يختلف تأثير الأداء اعتماداً على حمل العمل الخاص بك. كإرشادات عامة، يمكن أن يكون تأثير الكتابة والتثبيت حوالي 20-30٪ تأثير.
تؤدي إعادة تشغيل خادم قاعدة البيانات الأساسي أيضا إلى إعادة تشغيل النسخة المتماثلة الاحتياطية.
تكوين وضع الاستعداد الإضافي غير مدعوم.
لا يمكن جدولة تكوين مهام الإدارة التي بدأها العميل أثناء نافذة الصيانة المدارة.
تحدث الأحداث المخطط لها مثل حوسبة التحجيم وتخزين المقياس في وضع الاستعداد أولا ثم على الخادم الأساسي. حاليا، لا يفشل الخادم لهذه العمليات المخطط لها.
إذا تم تكوين فك التشفير المنطقي أو النسخ المتماثل المنطقي باستخدام خادم مرن تم تكوينه بواسطة التوفر، في حالة تجاوز الفشل إلى الخادم الاحتياطي، لا يتم نسخ فتحات النسخ المتماثل المنطقية إلى خادم الاستعداد. للحفاظ على فتحات النسخ المتماثل المنطقية وضمان تناسق البيانات بعد تجاوز الفشل، يوصى باستخدام ملحق PG Failover Slots. لمزيد من المعلومات حول كيفية تمكين هذا الملحق، يرجى الرجوع إلى الوثائق.
تكوين مناطق التوفر بين الوصول الخاص (VNET) والعام مع نقاط النهاية الخاصة غير مدعوم. يجب تكوين مناطق التوفر داخل VNET (تمتد عبر مناطق التوفر داخل منطقة) أو الوصول العام مع نقاط النهاية الخاصة.
يتم تكوين مناطق التوفر داخل منطقة واحدة فقط. لا يمكن تكوين مناطق التوفر عبر المناطق.
SLA
يوفر نموذج المنطقة اتفاقية مستوى الخدمة لوقت التشغيل بنسبة 99.95٪.
يوفر نموذج تكرار المنطقة اتفاقية مستوى الخدمة لوقت التشغيل بنسبة 99.99٪.
إنشاء قاعدة بيانات Azure ل PostgreSQL - خادم مرن مع تمكين منطقة التوفر
لمعرفة كيفية إنشاء قاعدة بيانات Azure ل PostgreSQL - خادم مرن للتوفر العالي مع مناطق التوفر، راجع التشغيل السريع: إنشاء قاعدة بيانات Azure ل PostgreSQL - خادم مرن في مدخل Microsoft Azure.
إعادة توزيع منطقة التوفر وترحيلها
لمعرفة كيفية تمكين أو تعطيل تكوين التوفر العالي في الخادم المرن في كل من نماذج التوزيع المتكررة للمنطقة ونماذج التوزيع المناطقية، راجع إدارة التوفر العالي في الخادم المرن.
مكونات قابلية الوصول العالية وسير العمل
إكمال المعاملة
يتم تسجيل عمليات الكتابة والتثبيت التي يتم تشغيلها في معاملة التطبيق أولا إلى WAL على الخادم الأساسي. ثم يتم دفقها إلى خادم الاستعداد باستخدام بروتوكول دفق Postgres. بمجرد استمرار السجلات على تخزين خادم الاستعداد، يتم الاعتراف بالخادم الأساسي لإكمال الكتابة. ثم يتم تأكيد التطبيق فقط على الالتزام بمعاملته. تضيف هذه الرحلة ذهابا وإيابا إضافية المزيد من زمن الانتقال إلى التطبيق الخاص بك. تعتمد النسبة المئوية للتأثير على التطبيق. لا تنتظر عملية الإقرار هذه حتى يتم تطبيق السجلات على خادم الاستعداد. خادم الاستعداد في وضع الاسترداد بشكل دائم حتى تتم ترقيته.
فحص الصحة
تتحقق المراقبة المرنة لصحة الخادم بشكل دوري من صحة كل من الصحة الأساسية والاستعدادية. بعد عمليات اختبار اتصال متعددة، إذا اكتشفت مراقبة السلامة أن الخادم الأساسي غير قابل للوصول، تبدأ الخدمة بعد ذلك تجاوز الفشل التلقائي إلى الخادم الاحتياطي. تستند خوارزمية مراقبة الصحة إلى نقاط بيانات متعددة لتجنب المواقف الإيجابية الخاطئة.
أوضاع تجاوز الفشل
يدعم الخادم المرن وضعي تجاوز الفشل، تجاوز الفشل المخطط له وتجاوز الفشل غير المخطط له. في كلا الوضعين، بمجرد قطع النسخ المتماثل، يقوم خادم الاستعداد بتشغيل الاسترداد قبل ترقيته كجهة أساسية ويفتح للقراءة/الكتابة. مع تحديث إدخالات DNS التلقائية بنقطة نهاية الخادم الأساسي الجديد، يمكن للتطبيقات الاتصال بالخادم باستخدام نفس نقطة النهاية. يتم إنشاء خادم الاستعداد الجديد في الخلفية، بحيث يمكن للتطبيق الخاص بك الحفاظ على الاتصال.
حالة قابلية الوصول العالية
تتم مراقبة صحة الخوادم الأساسية والخوادم الاحتياطية باستمرار، ويتم اتخاذ الإجراءات المناسبة لمعالجة المشكلات، بما في ذلك تشغيل تجاوز الفشل إلى خادم الاستعداد. يسرد الجدول أدناه حالات قابلية الوصول العالية المحتملة:
| الحالة | الوصف |
|---|---|
| تتم الآن تهيئة | في عملية إنشاء خادم احتياطي جديد. |
| النسخ المتماثل للبيانات | بعد إنشاء وضع الاستعداد، يتم اللحاق بالمرحلة الأساسية. |
| صحي | النسخ المتماثل في حالة ثابتة وصحية. |
| تجاوز الفشل | خادم قاعدة البيانات في عملية تجاوز الفشل في وضع الاستعداد. |
| إزالة وضع الاستعداد | في عملية حذف خادم الاستعداد. |
| غير ممكن | لم يتم تمكين قابلية الوصول العالية. |
إشعار
يمكنك تمكين قابلية الوصول العالية أثناء إنشاء الخادم أو في وقت لاحق أيضاً. إذا كنت تقوم بتمكين أو تعطيل التوفر العالي أثناء مرحلة ما بعد الإنشاء، يوصى بالعمل عندما يكون نشاط الخادم الأساسي منخفضا.
عمليات الحالة الثابتة
يتم توصيل تطبيقات عميل PostgreSQL بالخادم الأساسي باستخدام اسم خادم DB. يتم تقديم قراءات التطبيق مباشرة من الخادم الأساسي. في الوقت نفسه، يتم تأكيد عمليات التثبيت والكتابة إلى التطبيق فقط بعد استمرار بيانات السجل على كل من الخادم الأساسي والنسخة المتماثلة الاحتياطية. نظرا لهذه الرحلة الإضافية ذهابا وإيابا، يمكن للتطبيقات توقع زمن انتقال مرتفع للكتابات والتثبيتات. يمكنك مراقبة صحة قابلية الوصول العالية على المدخل.
- يتصل العملاء بالخادم المرن وينفذون عمليات الكتابة.
- يتم نسخ التغييرات إلى موقع الاستعداد.
- يتلقى الأساسي إقرارا.
- يتم الاعتراف بالكتابات/التثبيتات.
استعادة الخوادم عالية التوفر في نقطة زمنية
بالنسبة للخوادم المرنة التي تم تكوينها بتوافر عال، يتم نسخ بيانات السجل في الوقت الفعلي إلى خادم الاستعداد. يتم نسخ أي أخطاء مستخدم على الخادم الأساسي - مثل إسقاط عرضي لجدول أو تحديثات بيانات غير صحيحة، إلى النسخة المتماثلة الاحتياطية. لذلك، لا يمكنك استخدام الاستعداد للتعافي من مثل هذه الأخطاء المنطقية. للاسترداد من مثل هذه الأخطاء، يجب عليك إجراء استعادة في نقطة زمنية من النسخة الاحتياطية. باستخدام إمكانية استعادة نقطة زمنية للخادم المرن، يمكنك الاستعادة إلى الوقت قبل حدوث الخطأ. تتم استعادة خادم قاعدة بيانات جديد كخادم مرن لمنطقة واحدة مع اسم خادم جديد يوفره المستخدم لقواعد البيانات التي تم تكوينها بتوافر عال. يمكنك استخدام الخادم المستعادة لبعض حالات الاستخدام:
يمكنك استخدام الخادم المستعادة للإنتاج وتمكين قابلية الوصول العالية اختياريا مع نسخة متماثلة احتياطية على نفس المنطقة أو منطقة أخرى في نفس المنطقة.
إذا كنت تريد استعادة كائن، فقم بتصديره من خادم قاعدة البيانات المستعادة واستيراده إلى خادم قاعدة بيانات الإنتاج.
إذا كنت ترغب في استنساخ خادم قاعدة البيانات لأغراض الاختبار والتطوير أو الاستعادة لأي أغراض أخرى، يمكنك إجراء الاستعادة في نقطة زمنية.
لمعرفة كيفية إجراء استعادة في نقطة زمنية لخادم مرن، راجع استعادة خادم مرن في نقطة زمنية.
دعم تجاوز الفشل
تجاوز الفشل المخطط له
تتضمن أحداث التوقف المخطط لها تحديثات البرامج الدورية المجدولة من Azure وترقيات الإصدار الثانوي. يمكنك أيضا استخدام تجاوز فشل مخطط لإرجاع الخادم الأساسي إلى منطقة توفر مفضلة. عند تكوينها في قابلية وصول عالية، يتم تطبيق هذه العمليات أولا على النسخة المتماثلة الاحتياطية بينما تستمر التطبيقات في الوصول إلى الخادم الأساسي. بمجرد تحديث النسخة المتماثلة الاحتياطية، يتم استنزاف اتصالات الخادم الأساسي، ويتم تشغيل تجاوز الفشل، والذي يقوم بتنشيط النسخة المتماثلة الاحتياطية لتكون النسخة المتماثلة الأساسية بنفس اسم خادم قاعدة البيانات. يجب أن تعيد تطبيقات العميل الاتصال بنفس اسم خادم قاعدة البيانات بالخادم الأساسي الجديد ويمكنها استئناف عملياتها. يتم إنشاء خادم الاستعداد الجديد في نفس المنطقة مثل الأساسي القديم.
بالنسبة للعمليات الأخرى التي بدأها المستخدم مثل حساب المقياس أو التخزين على نطاق واسع، يتم تطبيق التغييرات في وضع الاستعداد أولا، متبوعا بالقاعدة الأساسية. حاليا، لم يتم تجاوز فشل الخدمة إلى وضع الاستعداد، وبالتالي أثناء تنفيذ عملية التحجيم على الخادم الأساسي، تواجه التطبيقات فترة توقف قصيرة.
يمكنك أيضا استخدام هذه الميزة لتجاوز الفشل إلى خادم الاستعداد مع تقليل وقت التعطل. على سبيل المثال، قد يكون الأساسي الخاص بك في منطقة توفر مختلفة عن التطبيق، بعد تجاوز الفشل غير المخطط له. تريد إعادة الخادم الأساسي إلى المنطقة السابقة للتكوين مع التطبيق الخاص بك.
عند تنفيذ هذه الميزة، يتم إعداد خادم الاستعداد أولا للتأكد من أنه منشغل بالمعاملات الأخيرة، ما يسمح للتطبيق بمتابعة تنفيذ عمليات القراءة/الكتابة. ثم يتم ترقية وضع الاستعداد، ويتم قطع الاتصالات بالمرحلة الأساسية. يمكن للتطبيق الخاص بك الاستمرار في الكتابة إلى الأساسي أثناء إنشاء خادم الاستعداد الجديد في الخلفية. فيما يلي الخطوات المتضمنة في تجاوز الفشل المخطط له:
| درج | الوصف | هل من المتوقع أن يكون وقت تعطل التطبيق؟ |
|---|---|---|
| 1 | انتظر حتى يكون خادم الاستعداد قد اشتعلت مع الأساسي. | لا |
| 2 | يبدأ نظام المراقبة الداخلية سير عمل تجاوز الفشل. | لا |
| 3 | يتم حظر عمليات كتابة التطبيق عندما يكون خادم الاستعداد قريبا من رقم تسلسل السجل الأساسي (LSN). | نعم |
| 4 | تتم ترقية خادم الاستعداد ليكون خادماً مستقلاً. | نعم |
| 5 | يتم تحديث سجل DNS بعنوان IP الخاص بخادم الاستعداد الجديد. | نعم |
| 6 | تطبيق لإعادة الاتصال واستئناف القراءة/الكتابة الخاصة به مع أساسي جديد. | لا |
| 7 | يتم إنشاء خادم الاستعداد الجديد في منطقة أخرى. | لا |
| 8 | يبدأ خادم الاستعداد في استرداد السجلات (من Azure Blob) التي فاتها أثناء إنشائه. | لا |
| 9 | يتم إنشاء حالة ثابتة بين الخادم الأساسي وخادم الاستعداد. | لا |
| 10 | اكتملت عملية تجاوز الفشل المخطط لها. | لا |
يبدأ وقت تعطل التطبيق في الخطوة رقم 3 ويمكن استئناف خطوة نشر العملية #5. تحدث بقية الخطوات في الخلفية دون التأثير على عمليات الكتابة والتثبيت للتطبيق.
تلميح
باستخدام الخادم المرن، يمكنك جدولة أنشطة الصيانة التي بدأها Azure اختياريا عن طريق اختيار نافذة مدتها 60 دقيقة في يوم من تفضيلك حيث من المتوقع أن تكون الأنشطة على قواعد البيانات منخفضة. قد تحدث مهام صيانة Azure مثل التصحيح أو ترقيات الإصدار الثانوي أثناء تلك النافذة. إذا لم تخن نافذة مخصصة، يتم تحديد نافذة مخصصة لنظام 1 ساعة بين الساعة 11 مساء و7 صباحا بالتوقيت المحلي للخادم الخاص بك. يتم أيضا تنفيذ أنشطة الصيانة التي بدأها Azure على النسخة المتماثلة الاحتياطية للخوادم المرنة التي تم تكوينها مع مناطق التوفر.
للحصول على قائمة بأحداث وقت التعطل المخطط لها المحتملة، راجع أحداث وقت التعطل المخطط لها.
تجاوز الفشل غير المخطط له
يمكن أن تحدث أوقات التوقف غير المخطط لها نتيجة لأعطال غير متوقعة مثل خطأ الأجهزة الأساسي ومشاكل الشبكات والأخطاء البرمجية. إذا انخفض خادم قاعدة البيانات المكون بقابلية وصول عالية بشكل غير متوقع، فسيتم تنشيط النسخة المتماثلة الاحتياطية ويمكن للعملاء استئناف عملياتهم. إذا لم يتم تكوينه بقابلية وصول عالية (HA)، ثم إذا فشلت محاولة إعادة التشغيل، يتم توفير خادم قاعدة بيانات جديد تلقائياً. بينما لا يمكن تجنب وقت تعطل غير مخطط له، يساعد الخادم المرن على تخفيف وقت التعطل عن طريق إجراء عمليات الاسترداد تلقائيا دون الحاجة إلى تدخل بشري.
للحصول على معلومات حول تجاوز الفشل غير المخطط له ووقت التعطل، بما في ذلك السيناريوهات المحتملة، راجع التخفيف من وقت التعطل غير المخطط له.
اختبارات تجاوز الفشل (تجاوز الفشل القسري)
مع تجاوز الفشل القسري، يمكنك محاكاة سيناريو انقطاع غير مخطط له أثناء تشغيل حمل عمل الإنتاج ومراقبة وقت تعطل التطبيق الخاص بك. يمكنك أيضا استخدام تجاوز الفشل القسري عندما يصبح الخادم الأساسي غير مستجيب.
يؤدي تجاوز الفشل القسري إلى خفض الخادم الأساسي وبدء سير عمل تجاوز الفشل الذي يتم فيه تنفيذ عملية ترقية وضع الاستعداد. بمجرد أن يكمل وضع الاستعداد عملية الاسترداد حتى آخر البيانات الملتزم بها، يتم ترقيته ليكون الخادم الأساسي. يتم تحديث سجلات DNS، ويمكن للتطبيق الاتصال بالخادم الأساسي الذي تمت ترقيته. يمكن أن يستمر تطبيقك في الكتابة إلى الأساسي أثناء إنشاء خادم الاستعداد الجديد في الخلفية، والذي لا يؤثر على وقت التشغيل.
فيما يلي الخطوات أثناء تجاوز الفشل القسري:
| درج | الوصف | هل من المتوقع أن يكون وقت تعطل التطبيق؟ |
|---|---|---|
| 1 | يتم إيقاف الخادم الأساسي بعد وقت قصير من تلقي طلب تجاوز الفشل. | نعم |
| 2 | يواجه التطبيق وقت تعطل لأن الخادم الأساسي معطل. | نعم |
| 3 | يكتشف نظام المراقبة الداخلية الفشل ويبدأ تجاوز الفشل إلى خادم الاستعداد. | نعم |
| 4 | يدخل خادم الاستعداد وضع الاسترداد قبل ترقيته بالكامل كخادم مستقل. | نعم |
| 5 | تنتظر عملية تجاوز الفشل حتى يكتمل الاسترداد في وضع الاستعداد. | نعم |
| 6 | بمجرد أن يكون الخادم لأعلى، يتم تحديث سجل DNS بنفس اسم المضيف ولكن باستخدام عنوان IP الخاص بالوقوف. | نعم |
| 7 | يمكن للتطبيق إعادة الاتصال بالخادم الأساسي الجديد واستئناف العملية. | لا |
| 8 | يتم إنشاء خادم الاستعداد في المنطقة المفضلة. | لا |
| 9 | يبدأ خادم الاستعداد في استرداد السجلات (من Azure Blob) التي فاتها أثناء إنشائه. | لا |
| 10 | يتم إنشاء حالة ثابتة بين الخادم الأساسي وخادم الاستعداد. | لا |
| 11 | اكتملت عملية تجاوز الفشل القسري. | لا |
من المتوقع أن يبدأ وقت تعطل التطبيق بعد الخطوة رقم 1 ويستمر حتى تكتمل الخطوة #6. تحدث بقية الخطوات في الخلفية دون التأثير على عمليات الكتابة والتثبيت للتطبيق.
هام
تتضمن عملية تجاوز الفشل من طرف إلى طرف (أ) الفشل في خادم الاستعداد بعد الفشل الأساسي و(ب) إنشاء خادم استعداد جديد في حالة ثابتة. نظرا لأن التطبيق الخاص بك يتحمل وقت تعطل حتى يكتمل تجاوز الفشل في وضع الاستعداد، يرجى قياس وقت التعطل من منظور التطبيق/العميل بدلا من عملية تجاوز الفشل الشاملة من طرف إلى طرف.
الاعتبارات أثناء تنفيذ تجاوز الفشل القسري
يمكن اعتبار وقت التشغيل الشامل الشامل أطول من وقت التعطل الفعلي الذي يواجهه التطبيق.
هام
لاحظ دائما وقت التعطل من منظور التطبيق!
لا تقم بإجراء عمليات تجاوز الفشل الفورية والخلفية. انتظر لمدة 15-20 دقيقة على الأقل بين عمليات تجاوز الفشل، ما يسمح بإنشاء خادم الاستعداد الجديد بشكل كامل.
يوصى بإجراء تجاوز فشل إجباري خلال فترة نشاط منخفض لتقليل وقت التعطل.
أفضل الممارسات لإحصائيات PostgreSQL بعد تجاوز الفشل
بعد تجاوز فشل PostgreSQL، تتضمن الآلية الأساسية للحفاظ على الأداء الأمثل لقاعدة البيانات فهم الأدوار المميزة لجداول pg_statistic pg_stat_ * . pg_statistic يضم الجدول إحصائيات المحسن، والتي تعتبر حاسمة لمخطط الاستعلام. تتضمن هذه الإحصائيات توزيعات البيانات داخل الجداول وتظل سليمة بعد تجاوز الفشل، ما يضمن أن مخطط الاستعلام يمكنه الاستمرار في تحسين تنفيذ الاستعلام بشكل فعال استنادا إلى معلومات توزيع البيانات التاريخية الدقيقة.
في المقابل، pg_stat_* تتم إعادة تعيين الجداول، التي تسجل إحصائيات النشاط مثل عدد عمليات الفحص، وقراءة المجموعات، والتحديثات، عند تجاوز الفشل. مثال على مثل هذا الجدول هو pg_stat_user_tables، الذي يتعقب النشاط للجداول المعرفة من قبل المستخدم. تم تصميم إعادة الضبط هذه لتعكس بدقة الحالة التشغيلية الأولية الجديدة ولكنها تعني أيضا فقدان مقاييس النشاط التاريخية التي يمكن أن تعلم عملية الإخلاء التلقائي والكفاءات التشغيلية الأخرى.
نظرا لهذا التمييز، فإن أفضل ممارسة بعد تجاوز فشل PostgreSQL هي تشغيل ANALYZE. يحدث pg_stat_* هذا الإجراء الجداول، مثل pg_stat_user_tables، مع إحصائيات نشاط جديدة، مما يساعد عملية الإخلاء التلقائي والتأكد من أن أداء قاعدة البيانات يظل مثاليا في دوره الجديد. هذه الخطوة الاستباقية سد الفجوة بين الحفاظ على إحصائيات المحسن الأساسية وتحديث مقاييس النشاط لتتماشى مع الحالة الحالية لقاعدة البيانات.
تجربة المنطقة لأسفل
النطاق: للتعافي من فشل على مستوى المنطقة، يمكنك إجراء استعادة في نقطة زمنية باستخدام النسخ الاحتياطي. يمكنك اختيار نقطة استعادة مخصصة مع أحدث وقت لاستعادة أحدث البيانات. يتم نشر خادم مرن جديد في منطقة أخرى غير متأثرة. يعتمد الوقت المستغرق للاستعادة على النسخ الاحتياطي السابق وحجم سجلات المعاملات للاسترداد.
لمزيد من المعلومات حول الاستعادة في نقطة زمنية، راجع النسخ الاحتياطي والاستعادة في قاعدة بيانات Azure لخادم PostgreSQL المرن.
تكرار المنطقة: يفشل الخادم المرن تلقائيا في الوصول إلى خادم الاستعداد في غضون 60-120 ثانية دون فقدان البيانات.
التكوينات بدون مناطق التوفر
على الرغم من أنه غير مستحسن، يمكنك تكوين الخادم المرن دون تمكين قابلية وصول عالية. بالنسبة للخوادم المرنة التي تم تكوينها دون توفر عال، توفر الخدمة تخزينا متكررا محليا بثلاث نسخ من البيانات، والنسخ الاحتياطي المتكرر للمنطقة (في المناطق التي يتم دعمها)، ومرونة الخادم المضمنة لإعادة تشغيل خادم متعطل تلقائيا ونقل الخادم إلى عقدة فعلية أخرى. يتم تقديم اتفاقية مستوى الخدمة لوقت التشغيل بنسبة 99.9٪ في هذا التكوين. أثناء أحداث تجاوز الفشل المخطط لها أو غير المخطط لها، إذا تعطل الخادم، تحافظ الخدمة على توفر الخوادم باستخدام الإجراء التلقائي التالي:
- يتم توفير جهاز حوسبة ظاهري جديد يعمل بنظام Linux.
- يتم تعيين التخزين مع ملفات البيانات إلى الجهاز الظاهري الجديد.
- يتم إحضار محرك قاعدة بيانات PostgreSQL عبر الإنترنت على الجهاز الظاهري الجديد.
توضح الصورة أدناه الانتقال بين الجهاز الظاهري وفشل التخزين.
التعافي من الكوارث عبر المناطق واستمرارية الأعمال
في حالة حدوث كارثة على مستوى المنطقة، يمكن ل Azure توفير الحماية من الكوارث الجغرافية الإقليمية أو الكبيرة مع التعافي من الكوارث من خلال الاستفادة من منطقة أخرى. لمزيد من المعلومات حول بنية التعافي من الكوارث في Azure، راجع Azure إلى بنية التعافي من الكوارث في Azure.
يوفر الخادم المرن ميزات تحمي البيانات وتخفف من وقت التعطل لقواعد البيانات المهمة أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها. بناء على البنية الأساسية ل Azure التي توفر مرونة وتوافرا قويا، يوفر الخادم المرن ميزات استمرارية الأعمال التي توفر الحماية من الأخطاء، وتعالج متطلبات وقت الاسترداد، ويقلل من التعرض لفقدان البيانات. أثناء تصميم التطبيقات الخاصة بك، يجب مراعاة التسامح مع وقت التعطل - هدف وقت الاسترداد (RTO)، والتعرض لفقدان البيانات - هدف نقطة الاسترداد (RPO). على سبيل المثال، تتطلب قاعدة البيانات المهمة للأعمال وقت تشغيل أكثر صرامة من قاعدة بيانات الاختبار.
التعافي من الكوارث في المنطقة الجغرافية متعددة المناطق
نسخ احتياطي جغرافي مكرر واستعادة
توفر النسخ الاحتياطية والاستعادة المتكررة جغرافيا القدرة على استعادة الخادم في منطقة مختلفة في حالة وقوع كارثة. كما أنه يوفر قدرة على الصمود لا تقل عن 99.99999999999999 بالمئة (رقم تسعة 16 مرة) لعناصر النسخ الاحتياطي على مدار عام.
لا يمكن تكوين النسخ الاحتياطي المتكرر جغرافياً إلا في وقت إنشاء الخادم. عندما يتم تكوين الخادم باستخدام نسخة احتياطية مكررة جغرافياً، يتم نسخ بيانات النسخ الاحتياطي وسجلات المعاملات إلى المنطقة المقترنة بشكل غير متزامن من خلال النسخ المتماثل للتخزين.
لمزيد من المعلومات حول النسخ الاحتياطي والاستعادة المتكررة جغرافيا، راجع النسخ الاحتياطي والاستعادة المتكررة جغرافيا.
قراءة النسخ المتماثلة
يمكن نشر النسخ المتماثلة للقراءة عبر المناطق لحماية قواعد البيانات الخاصة بك من حالات الفشل على مستوى المنطقة. يتم تحديث النسخ المتماثلة للقراءة بشكل غير متزامن باستخدام تقنية النسخ المتماثل المادي ل PostgreSQL، ويمكن أن تتأخر عن النسخة الأساسية. يتم دعم النسخ المتماثلة للقراءة في الأغراض العامة وطبقات الحوسبة المحسنة للذاكرة.
لمزيد من المعلومات حول ميزات واعتبارات قراءة النسخ المتماثلة، راجع قراءة النسخ المتماثلة.
الكشف عن الانقطاع والإعلام والإدارة
إذا تم تكوين الخادم الخاص بك باستخدام نسخة احتياطية جغرافية مكررة، يمكنك إجراء استعادة جغرافية في المنطقة المقترنة. يتم توفير خادم جديد واسترداده إلى آخر البيانات المتوفرة التي تم نسخها إلى هذه المنطقة.
يمكنك أيضا استخدام النسخ المتماثلة للقراءة عبر المناطق. في حالة فشل المنطقة، يمكنك تنفيذ عملية التعافي من الكوارث عن طريق ترقية النسخة المتماثلة للقراءة لتكون خادما مستقلا قابلا للقراءة والكتابة. من المتوقع أن يصل هدف نقطة الاسترداد إلى 5 دقائق (فقدان البيانات المحتمل) إلا في حالة الفشل الإقليمي الحاد عندما يمكن أن يكون RPO قريبا من تأخر النسخ المتماثل في وقت الفشل.
لمزيد من المعلومات حول التخفيف من حدة وقت التعطل غير المخطط له والتعافي بعد الكارثة الإقليمية، راجع التخفيف من وقت التعطل غير المخطط له.