إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
توضح هذه المقالة قابلية الوصول العالية في قاعدة بيانات Azure ل PostgreSQL، والتي تتضمن مناطق التوفروالاسترداد عبر المناطق واستمرارية الأعمال. للحصول على نظرة عامة أكثر تفصيلا على الموثوقية في Azure، راجع موثوقية Azure.
تدعم قاعدة بيانات Azure ل PostgreSQL قابلية الوصول العالية عن طريق توفير النسخ المتماثلة الأساسية والاحتياطية المنفصلة فعليا، إما داخل نفس منطقة التوفر (المنطقة) أو عبر مناطق التوفر (المنطقة الزائدة عن الحاجة). تم تصميم نموذج قابلية الوصول العالية هذا لضمان عدم فقد البيانات الملتزمة بها أثناء الفشل. في إعداد قابلية الوصول العالية (HA)، يتم الالتزام بالبيانات بشكل متزامن لكل من الخوادم الأساسية والخوادم الاحتياطية. تم تصميم النموذج بحيث لا تصبح قاعدة البيانات نقطة فشل واحدة في بنية البرنامج. لمزيد من المعلومات حول التوفر العالي ودعم منطقة التوفر، راجع دعم منطقة التوفر.
دعم منطقة القابلية للوصول
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل كل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
تدعم قاعدة بيانات Azure ل PostgreSQL كلا من نماذج المنطقة الزائدة عن الحاجة والمنطقة لتكوينات قابلية الوصول العالية. يتيح كل من تكوينات قابلية الوصول العالية إمكانية تجاوز الفشل التلقائي مع عدم فقدان البيانات أثناء كل من الأحداث المخطط لها وغير المخطط لها.
المنطقة زائدة عن الحاجة. تنشر قابلية الوصول العالية المكررة للمنطقة نسخة متماثلة احتياطية في منطقة مختلفة مع إمكانية تجاوز الفشل التلقائي. يوفر تكرار المنطقة أعلى مستوى من التوفر، ولكنك تحتاج إلى تكوين تكرار التطبيق عبر المناطق. لهذا السبب، اختر تكرار المنطقة عندما تريد الحماية من حالات فشل مستوى منطقة التوفر وعندما يكون زمن الانتقال عبر مناطق التوفر مقبولا. بينما يمكن أن يكون هناك بعض تأثير زمن الانتقال على عمليات الكتابة والتثبيت بسبب النسخ المتماثل المتزامن، فإنه لا يؤثر على استعلامات القراءة. هذا التأثير خاص بأحمال العمل الخاصة بك ونوع SKU الذي تحدده والمنطقة.
يمكنك اختيار المنطقة ومناطق التوفر لكل من الخوادم الأساسية والخوادم الاحتياطية. يتم توفير خادم النسخة المتماثلة الاحتياطية في منطقة التوفر المختارة في نفس المنطقة مع حساب وتخزين وتكوين شبكة مماثلة كخادم أساسي. يتم تخزين ملفات البيانات وملفات سجل المعاملات (سجلات الكتابة المسبقة، والمعروفة أيضا باسم WAL) على مساحة تخزين متكررة محليا (LRS) داخل كل منطقة توافر خدمات، وتخزين ثلاث نسخ بيانات تلقائيا. يوفر التكوين المتكرر للمنطقة عزلا ماديا للمكدس بأكمله بين الخوادم الأساسية وخوادم الاستعداد.
يتوفر خيار المنطقة المكررة فقط في المناطق التي لديها دعم لمناطق التوفر.
المنطقة الزائدة عن الحاجة غير مدعومة لما يلي:
طبقة الحوسبة القابلة للحمل
المناطق ذات التوفر في منطقة واحدة
منطقة. اختر توزيع نطاقي عندما تريد تحقيق أعلى مستوى من التوفر داخل منطقة توفر واحدة، ولكن مع أقل زمن انتقال للشبكة. يمكنك اختيار المنطقة ومنطقة التوفر لنشر كل من خادم قاعدة البيانات الأساسي. يتم توفير خادم النسخة المتماثلة الاحتياطية وإدارتها تلقائيا في نفس منطقة التوفر - مع حساب وتخزين وتكوين شبكة مماثلة - كخادم أساسي. يحمي التكوين النطاقي قواعد البيانات الخاصة بك من حالات الفشل على مستوى العقدة ويساعد أيضا في تقليل وقت تعطل التطبيق أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها. يتم نسخ البيانات من الخادم الأساسي إلى النسخة المتماثلة الاحتياطية في وضع متزامن. في حالة حدوث أي انقطاع في الخادم الأساسي، يفشل الخادم تلقائيا في النسخة المتماثلة الاحتياطية.
يتوفر خيار التوزيع النطاقي في جميع مناطق Azure حيث يمكنك نشر Flexible Server.
إشعار
يتصرف كل من نماذج التوزيع المناطقية ونماذج التوزيع المتكررة في المنطقة بنفس الطريقة من الناحية المعمارية. تنطبق المناقشات المختلفة في الأقسام التالية على كليهما ما لم يتم استدعاؤها بخلاف ذلك.
تكوين مرونة المنطقة في المدخل
يمكنك تكوين قابلية الوصول العالية (HA) بطريقتين: قابلية الوصول العالية المتكررة في المنطقة، والتي تضع الخادم الاحتياطي في منطقة إتاحة مختلفة لتحقيق أقصى قدر من المرونة، أو قابلية الوصول العالية في نفس المنطقة، والتي تنشر خادم الاستعداد في نفس المنطقة مثل الخادم الأساسي لتقليل زمن الوصول.
لتبسيط التكوين وضمان مرونة المنطقة، توفر البوابة خيار مرونة المنطقة مع زري اختيار: ممكن ومعطل. يحاول تحديد ممكن إنشاء خادم الاستعداد في منطقة توفر مختلفة (وضع HA المتكرر في المنطقة). إذا كانت المنطقة لا تدعم قابلية الارتفاع الاحتياطية المتكررة للمنطقة، فيمكنك تحديد خانة الاختيار الاحتياطية (المميزة في الصورة التالية) لتمكين قابلية الارتفاع في نفس المنطقة بدلا من ذلك.
عند اختيار مربع اختيار الاحتياط، ينشئ النظام خادم الاحتياط في نفس المنطقة. إذا أصبحت سعة المناطق متاحة لاحقا، سيخبرك Azure حتى تتمكن من اختيار الانتقال إلى تكوين HA مكرر في المنطقة باستخدام PITR أو قراءة النسخ المقلدة. إذا لم تقم بتحديد خانة الاختيار ولم تكن سعة المنطقة غير متوفرة، فسيفشل تمكين HA. يفرض هذا التصميم HA المتكرر في المنطقة كإعداد افتراضي مع توفير احتياطي متحكم فيه لقابلية الإرسال العالية في نفس المنطقة، مما يضمن أن أحمال العمل تحقق في النهاية مرونة كاملة للمنطقة دون تدخل يدوي.
ميزات قابلية الوصول العالية
يتم نشر نسخة متماثلة احتياطية في نفس تكوين الجهاز الظاهري - بما في ذلك vCores والتخزين وإعدادات الشبكة - كخادم أساسي.
يمكنك إضافة دعم منطقة التوفر لخادم قاعدة بيانات موجود.
يمكنك إزالة النسخة المتماثلة الاحتياطية عن طريق تعطيل قابلية الوصول العالية.
يمكنك اختيار مناطق التوفر لخوادم قاعدة البيانات الأساسية والاستعدادية لتوفر المنطقة المكرر.
يتم تنفيذ عمليات مثل الإيقاف والبدء وإعادة التشغيل على كل من خوادم قاعدة البيانات الأساسية وخوادم قاعدة البيانات الاحتياطية في نفس الوقت.
في النماذج المتكررة للمنطقة والمناطق، يقوم خادم قاعدة البيانات الأساسي بإجراء نسخ احتياطية تلقائية بشكل دوري. في الوقت نفسه، تقوم النسخة المتماثلة الاحتياطية بأرشفة سجلات المعاملات باستمرار في تخزين النسخ الاحتياطي. إذا كانت المنطقة تدعم مناطق التوفر، يتم تخزين بيانات النسخ الاحتياطي على التخزين المتكرر للمنطقة (ZRS). في المناطق التي لا تدعم مناطق التوفر، يتم تخزين بيانات النسخ الاحتياطي على التخزين المحلي المكرر (LRS).
يتصل العملاء دائما باسم المضيف النهائي لخادم قاعدة البيانات الأساسي.
يتم أيضا تطبيق أي تغييرات على معلمات الخادم على النسخة المتماثلة الاحتياطية.
يمكنك إعادة تشغيل الخادم لالتقاط أي تغييرات ثابتة في معلمات الخادم.
تحدث أنشطة الصيانة الدورية مثل ترقيات الإصدار الثانوي في وضع الاستعداد أولا. لتقليل وقت التوقف عن العمل، يتم ترقية وضع الاستعداد إلى الأساسي بحيث يمكن أن تستمر أحمال العمل أثناء تطبيق مهام الصيانة على العقدة المتبقية.
إشعار
لضمان وظائف قابلية الوصول العالية بشكل صحيح، قم بتكوين قيم معلمات max_replication_slots الخادم والخادم max_wal_senders . يتطلب التوفر العالي أربعة من كل منها للتعامل مع عمليات تجاوز الفشل والترقيات السلسة. للحصول على إعداد عالي التوافر مع خمسة نسخ قراءة و12 فتحة تكرار منطقية، اضبط قيم المعلمات إلى max_replication_slotsmax_wal_senders 21. يعد هذا التكوين ضروريا لأن كل نسخة متماثلة للقراءة وفتحة نسخ متماثل منطقية تتطلب واحدة من كل منهما، بالإضافة إلى الأربعة اللازمة لقابلية الوصول العالية لتعمل بشكل صحيح. لمزيد من المعلومات حول max_replication_slots المعلمات max_wal_senders ، يرجى الرجوع إلى الوثائق.
مراقبة الصحة عالية التوفر
توفر مراقبة حالة التوفر العالي (HA) في قاعدة بيانات Azure ل PostgreSQL نظرة عامة مستمرة على صحة وجاهزية المثيلات التي تدعم HA. تطبق ميزة المراقبة هذه إطار عمل Azure Resource Health Check (RHC) للكشف والتنبيه بشأن أي مشكلات قد تؤثر على جاهزية تجاوز الفشل لقاعدة البيانات أو التوفر العام. من خلال تقييم المقاييس الرئيسية مثل حالة الاتصال وحالة تجاوز الفشل وصحة النسخ المتماثل للبيانات، تتيح مراقبة حالة صحة HA استكشاف الأخطاء وإصلاحها بشكل استباقي وتساعد في الحفاظ على وقت تشغيل قاعدة البيانات وأدائها.
استخدم مراقبة الحالة الصحية لحمض الهيالورونيك من أجل:
- احصل على رؤى في الوقت الحقيقي حول صحة كل من النسخ المتماثلة الأساسية والاحتياطية، مع مؤشرات الحالة التي تكشف عن المشكلات المحتملة، مثل تدهور الأداء أو حظر الشبكة.
- قم بإعداد تنبيهات للإشعارات في الوقت المناسب حول أي تغييرات في حالة HA، حتى تتمكن من اتخاذ إجراء فوري لمعالجة الاضطرابات المحتملة.
- تحسين جاهزية تجاوز الفشل عن طريق تحديد المشكلات ومعالجتها قبل أن تؤثر على عمليات قاعدة البيانات.
للحصول على دليل مفصل حول تكوين حالات سلامة HA، راجع مراقبة حالة صحة قابلية الوصول العالية (HA) لقاعدة بيانات Azure ل PostgreSQL.
قيود قابلية الوصول العالية
نظرا للنسخ المتماثل المتزامن إلى الخادم الاحتياطي ، خاصة مع تكوين متكرر للمنطقة ، يمكن أن تواجه التطبيقات زمن انتقال كتابة وتنفيذ مرتفع.
لا يمكنك استخدام النسخة المتماثلة الاحتياطية لاستعلامات القراءة.
اعتمادا على حمل العمل والنشاط على الخادم الأساسي، قد تستغرق عملية تجاوز الفشل أكثر من 120 ثانية لأن النسخة المتماثلة في وضع الاستعداد تحتاج إلى الاسترداد قبل ترقيتها.
عادة ما يسترد خادم الاستعداد ملفات WAL بمعدل 40 ميغابايت/ثانية. بالنسبة للإصدارات الأكبر ، يمكن أن يزيد هذا المعدل إلى 200 ميجابايت / ثانية. إذا تجاوز حمل العمل هذا الحد، يمكنك أن تواجه وقتا ممتدا لإكمال الاسترداد إما أثناء تجاوز الفشل أو بعد إنشاء وضع الاستعداد الجديد.
تؤدي إعادة تشغيل خادم قاعدة البيانات الأساسي أيضا إلى إعادة تشغيل النسخة المتماثلة الاحتياطية.
لا يمكنك تكوين وضع استعداد إضافي.
لا يمكنك جدولة مهام الإدارة التي بدأها العميل أثناء نافذة الصيانة المدارة.
تحدث الأحداث المخطط لها مثل الحوسبة على نطاق واسع وتخزين القياس في وضع الاستعداد أولا ثم على الخادم الأساسي. حاليا، لا يفشل الخادم لهذه العمليات المخطط لها.
إذا قمت بتكوين فك الترميز المنطقي أو التكرار المنطقي على خادم مرن مدعوم ب HA:
- في PostgreSQL 16 والإصدارات الأقدم، لا يتم الاحتفاظ بفتحات النسخ المتماثل المنطقي على خادم الاستعداد بعد تجاوز الفشل بشكل افتراضي.
- لضمان استمرار عمل النسخ المتماثل المنطقي بعد تجاوز الفشل، تحتاج إلى تمكين الملحق
pg_failover_slotsوتكوين الإعدادات الداعمة مثلhot_standby_feedback = on. - بدءا من PostgreSQL 17 ، يتم دعم مزامنة الفتحة في الأصل. إذا قمت بتمكين تكوينات PostgreSQL الصحيحة (
sync_replication_slots،hot_standby_feedback) ، الاحتفاظ بفتحات النسخ المتماثل المنطقي تلقائيا بعد تجاوز الفشل ، ولا يلزم وجود ملحق. - للحصول على خطوات الإعداد والمتطلبات الأساسية، يرجى الرجوع إلى وثائق ملحق PG_Failover_Slots .
تكوين مناطق التوفر بين الوصول الخاص (الشبكة الظاهرية) والوصول العام مع نقاط النهاية الخاصة غير مدعوم. يجب تكوين مناطق التوفر داخل شبكة ظاهرية (تمتد عبر مناطق التوفر داخل المنطقة) أو الوصول العام باستخدام نقاط النهاية الخاصة.
يمكنك فقط تكوين مناطق التوفر داخل منطقة واحدة. لا يمكنك تكوين مناطق التوفر عبر المناطق.
SLA
يوفر نموذج زونال وقت تشغيل لنظام SLA حوالي 99.95%.
نموذج التكرار في المنطقة يوفر وقت تشغيل لاتفاقية مستوى الخدمة (SLA) حوالي 99.99%.
إنشاء قاعدة بيانات Azure ل PostgreSQL مع تمكين منطقة التوفر
لمعرفة كيفية إنشاء قاعدة بيانات Azure ل PostgreSQL للحصول على قابلية وصول عالية مع مناطق التوفر، راجع التشغيل السريع: إنشاء قاعدة بيانات Azure ل PostgreSQL في مدخل Microsoft Azure.
إعادة توزيع منطقة التوفر وترحيلها
لمعرفة كيفية تمكين أو تعطيل تكوين قابلية الوصول العالية في الخادم المرن لديك في كل من نماذج النشر المتكررة للمنطقة والمناطق، راجع إدارة قابلية التوفر العالية في الخادم المرن.
مكونات قابلية الوصول العالية وسير العمل
إكمال المعاملة
تؤدي معاملة التطبيق إلى عملية كتابة والتزام تسجل أولا إلى WAL على الخادم الرئيسي. يقوم الخادم الأساسي بدفق هذه السجلات إلى خادم الاستعداد باستخدام بروتوكول دفق Postgres. عندما يستمر تخزين الخادم الاحتياطي في السجلات، يقر الخادم الأساسي بإكمال الكتابة. لا يلتزم التطبيق معاملته إلا بعد هذا الإقرار. تضيف هذه الرحلة الإضافية ذهابا وإيابا زمن انتقال إلى طلبك. تعتمد نسبة التأثير على التطبيق. لا تنتظر عملية الإقرار هذه حتى يتم تطبيق السجلات على خادم الاستعداد. يظل خادم الاستعداد في وضع الاسترداد حتى يتم ترقيته.
فحص الصحة
تتحقق المراقبة المرنة لسلامة الخادم بشكل دوري من صحة كل من الخوادم الأساسية والاحتياطية. بعد إختبارات الاتصال المتعددة، إذا اكتشفت مراقبة السلامة أنه لا يمكن الوصول إلى خادم أساسي، تبدأ الخدمة تجاوز الفشل التلقائي إلى الخادم الاحتياطي. تستخدم خوارزمية مراقبة الصحة نقاط بيانات متعددة لتجنب المواقف الإيجابية الخاطئة.
أوضاع تجاوز الفشل
يدعم الخادم المرن وضعي تجاوز الفشل، تجاوز الفشل المخطط له وتجاوز الفشل غير المخطط له. في كلا الوضعين، بمجرد توقف النسخ المتماثل، يقوم خادم الاستعداد بتشغيل الاسترداد قبل الترقية كأساسي ويفتح للقراءة/الكتابة. مع تحديث إدخالات DNS التلقائية بنقطة نهاية الخادم الأساسي الجديدة، يمكن للتطبيقات الاتصال بالخادم باستخدام نفس نقطة النهاية. يتم إنشاء خادم الاستعداد الجديد في الخلفية، بحيث يمكن للتطبيق الخاص بك الحفاظ على الاتصال.
حالة قابلية الوصول العالية
يراقب النظام باستمرار صحة الخوادم الأساسية والاحتياطية. يتخذ الإجراءات المناسبة لإصلاح المشكلات، بما في ذلك تشغيل تجاوز الفشل إلى الخادم الاحتياطي. يسرد الجدول التالي حالات قابلية الوصول العالية المحتملة:
| الحالة | وصف |
|---|---|
| تتم الآن تهيئة | في عملية إنشاء خادم احتياطي جديد. |
| النسخ المتماثل للبيانات | بعد إنشاء وضع الاستعداد، يتم اللحاق بالمرحلة الأساسية. |
| صحي | النسخ المتماثل في حالة ثابتة وصحية. |
| تجاوز الفشل | خادم قاعدة البيانات في عملية تجاوز الفشل في وضع الاستعداد. |
| إزالة وضع الاستعداد | في عملية حذف خادم الاستعداد. |
| غير ممكن | لم يتم تمكين قابلية الوصول العالية. |
إشعار
يمكنك تمكين قابلية الوصول العالية أثناء إنشاء الخادم أو في وقت لاحق. إذا قمت بتمكين قابلية الوصول العالية أو تعطيلها أثناء مرحلة ما بعد الإنشاء، فقم بذلك عندما يكون نشاط الخادم الأساسي منخفضا.
عمليات الحالة الثابتة
تتصل تطبيقات عميل PostgreSQL بالخادم الأساسي باستخدام اسم خادم قاعدة البيانات. يخدم الخادم الأساسي قراءات التطبيق مباشرة. في الوقت نفسه، يتلقى التطبيق تأكيدا للالتزامات ويكتب فقط بعد استمرار بيانات السجل على كل من الخادم الأساسي والنسخة المتماثلة الاحتياطية. نظرا لهذه الرحلة الإضافية ذهابا وإيابا، يمكن للتطبيقات توقع زمن انتقال مرتفع للكتابات والتثبيتات. يمكنك مراقبة صحة قابلية الوصول العالية على المدخل.
- يتصل العملاء بالخادم المرن وينفذون عمليات الكتابة.
- يتم نسخ التغييرات إلى موقع الاستعداد.
- يتلقى الأساسي إقرارا.
- يتم الاعتراف بالكتابة والالتزامات.
استعادة الخوادم عالية التوفر في نقطة زمنية
بالنسبة للخوادم المرنة التي تم تكوينها بقابلية وصول عالية، يقوم النظام بنسخ بيانات السجل في الوقت الفعلي إلى الخادم الاحتياطي. يتم نسخ أي أخطاء مستخدم على الخادم الأساسي - مثل السقوط العرضي لجدول أو تحديثات البيانات غير الصحيحة - إلى النسخة المتماثلة الاحتياطية. لذلك ، لا يمكنك استخدام وضع الاستعداد للتعافي من مثل هذه الأخطاء المنطقية. للتعافي من مثل هذه الأخطاء، يجب عليك إجراء استعادة في نقطة زمنية من النسخة الاحتياطية. باستخدام إمكانية الاستعادة في نقطة زمنية لخادم مرن، يمكنك الاستعادة إلى الوقت السابق لحدوث الخطأ. تتم استعادة خادم قاعدة بيانات جديد كخادم مرن لمنطقة واحدة مع اسم خادم جديد يوفره المستخدم لقواعد البيانات التي تم تكوينها بتوافر عال. يمكنك استخدام الخادم المستعاد لعدة حالات استخدام:
استخدم الخادم المستعاد للإنتاج وقم اختياريا بتمكين قابلية الوصول العالية باستخدام النسخة المتماثلة في وضع الاستعداد إما في نفس المنطقة أو منطقة أخرى في نفس المنطقة.
إذا كنت تريد استعادة كائن، فقم بتصديره من خادم قاعدة البيانات المستعادة واستيراده إلى خادم قاعدة بيانات الإنتاج.
إذا كنت ترغب في استنساخ خادم قاعدة البيانات لأغراض الاختبار والتطوير أو الاستعادة لأي أغراض أخرى، يمكنك إجراء الاستعادة في نقطة زمنية.
لمعرفة كيفية إجراء استعادة في نقطة زمنية لخادم مرن، راجع استعادة خادم مرن في نقطة زمنية.
دعم تجاوز الفشل
تجاوز الفشل المخطط له
تتضمن أحداث التوقف المخطط لها تحديثات البرامج الدورية المجدولة من Azure وترقيات الإصدار الثانوي. يمكنك أيضا استخدام تجاوز فشل مخطط لإرجاع الخادم الأساسي إلى منطقة توفر مفضلة. عند تكوين قابلية وصول عالية، تنطبق هذه العمليات أولا على النسخة المتماثلة الاحتياطية بينما تستمر التطبيقات في الوصول إلى الخادم الأساسي. بمجرد أن تقوم العملية بتحديث النسخة المتماثلة في وضع الاستعداد، فإنها تستنزف اتصالات الخادم الأساسي وتؤدي إلى تجاوز الفشل الذي ينشط النسخة المتماثلة الاحتياطية كخادم أساسي بنفس اسم خادم قاعدة البيانات. تعيد تطبيقات العميل الاتصال بنفس اسم خادم قاعدة البيانات بالخادم الأساسي الجديد ويمكنها استئناف عملياتها. تنشئ العملية خادم احتياطيا جديدا في نفس المنطقة مثل الخادم الأساسي القديم.
بالنسبة للعمليات الأخرى التي بدأها المستخدم مثل الحوسبة على نطاق واسع أو تخزين القياس، تطبق العملية التغييرات على وضع الاستعداد أولا، ثم الأساسي. حاليا، لا تفشل الخدمة في وضع الاستعداد. وبالتالي، أثناء تشغيل عملية القياس على الخادم الأساسي، تواجه التطبيقات وقت تعطل قصير.
يمكنك أيضا استخدام هذه الميزة لتجاوز الفشل إلى خادم الاستعداد مع تقليل وقت التعطل. على سبيل المثال، قد يكون الخادم الأساسي في منطقة توفر مختلفة عن التطبيق بعد تجاوز الفشل غير المخطط له. تريد إعادة الخادم الأساسي إلى المنطقة السابقة للتكوين مع التطبيق الخاص بك.
عند تنفيذ هذه الميزة، تقوم العملية أولا بإعداد الخادم الاحتياطي للتأكد من أنه يلحق بالمعاملات الأخيرة، مما يسمح للتطبيق بمواصلة إجراء عمليات القراءة والكتابة. تعزز العملية وضع الاستعداد وتقطع الاتصالات بالأساسي. يمكن أن يستمر تطبيقك في الكتابة إلى الأساسي بينما تنشئ العملية خادما احتياطيا جديدا في الخلفية. يصف الجدول التالي الخطوات المتضمنة في تجاوز الفشل المخطط له:
| درج | وصف | هل من المتوقع أن يكون وقت تعطل التطبيق؟ |
|---|---|---|
| 1 | انتظر حتى يلحق الخادم الاحتياطي بالأساسي. | No |
| 2 | يبدأ نظام المراقبة الداخلية سير عمل تجاوز الفشل. | No |
| 3 | يتم حظر عمليات كتابة التطبيق عندما يكون خادم الاستعداد قريبا من رقم تسلسل السجل الأساسي (LSN). | Yes |
| 4 | تتم ترقية خادم الاستعداد ليكون خادماً مستقلاً. | Yes |
| 5 | يتم تحديث سجل DNS بعنوان IP الخاص بخادم الاستعداد الجديد. | Yes |
| 6 | يعيد التطبيق الاتصال ويستأنف القراءة / الكتابة مع أساسي جديد. | No |
| 7 | يتم إنشاء خادم الاستعداد الجديد في منطقة أخرى. | No |
| 8 | يبدأ خادم الاستعداد في استرداد السجلات (من Azure Blob) التي فاتها أثناء إنشائه. | No |
| 9 | يتم إنشاء حالة ثابتة بين الخادم الأساسي وخادم الاستعداد. | No |
| 10 | اكتملت عملية تجاوز الفشل المخطط لها. | No |
يبدأ وقت تعطل التطبيق في الخطوة 3 ويمكن أن يستأنف التشغيل بعد الخطوة 5. تحدث بقية الخطوات في الخلفية دون التأثير على عمليات الكتابة والتثبيت للتطبيق.
تلميح
باستخدام الخادم المرن، يمكنك اختياريا جدولة أنشطة الصيانة التي بدأها Azure عن طريق اختيار نافذة مدتها 60 دقيقة في يوم تفضله عندما يتوقع أن تكون الأنشطة على قواعد البيانات منخفضة. تحدث مهام صيانة Azure مثل التصحيح أو ترقيات الإصدار الثانوي خلال تلك النافذة. إذا لم تختر نافذة مخصصة، يخصص النظام نافذة مدتها ساعة واحدة بين الساعة 11 مساء و7 صباحا بالتوقيت المحلي للخادم الخاص بك. تعمل أنشطة الصيانة التي بدأها Azure أيضا على النسخة المتماثلة الاحتياطية للخوادم المرنة التي تم تكوينها مع مناطق التوفر.
للحصول على قائمة بأحداث وقت التعطل المخطط لها المحتملة، راجع أحداث وقت التعطل المخطط لها.
تجاوز الفشل غير المخطط له
يمكن أن تحدث أوقات تعطل غير مخطط لها نتيجة للاضطرابات غير المتوقعة مثل أعطال الأجهزة الأساسية ومشكلات الشبكات وأخطاء البرامج. إذا تعطل خادم قاعدة البيانات الذي تم تكوينه بقابلية وصول عالية بشكل غير متوقع، فإن العملية تنشط النسخة المتماثلة الاحتياطية ويمكن للعملاء استئناف عملياتهم. إذا لم تقم بتكوين قابلية الوصول العالية (HA)، وفشلت محاولة إعادة التشغيل، فستقوم العملية تلقائيا بتوفير خادم قاعدة بيانات جديد. على الرغم من أنه لا يمكن تجنب وقت التوقف عن العمل غير المخطط له، إلا أن الخادم المرن يساعد في التخفيف من وقت التوقف عن العمل عن طريق إجراء عمليات الاسترداد تلقائيا دون الحاجة إلى تدخل بشري.
للحصول على معلومات حول تجاوز الفشل غير المخطط له ووقت التعطل، بما في ذلك السيناريوهات المحتملة، راجع التخفيف من وقت التعطل غير المخطط له.
اختبار تجاوز الفشل (تجاوز الفشل القسري)
مع تجاوز الفشل القسري، يمكنك محاكاة سيناريو انقطاع غير مخطط له أثناء تشغيل حمل عمل الإنتاج ومراقبة وقت تعطل التطبيق الخاص بك. يمكنك أيضا استخدام تجاوز الفشل القسري عندما يصبح الخادم الأساسي غير مستجيب.
يؤدي تجاوز الفشل القسري إلى خفض الخادم الأساسي وبدء سير عمل تجاوز الفشل الذي يتم فيه تنفيذ عملية ترقية وضع الاستعداد. بمجرد أن يكمل وضع الاستعداد عملية الاسترداد حتى آخر بيانات ملتزم بها، يتم ترقيته ليكون الخادم الأساسي. يتم تحديث سجلات DNS، ويمكن للتطبيق الاتصال بالخادم الأساسي الذي تمت ترقيته. يمكن أن يستمر تطبيقك في الكتابة إلى الأساسي أثناء إنشاء خادم الاستعداد الجديد في الخلفية، والذي لا يؤثر على وقت التشغيل.
يصف الجدول التالي الخطوات أثناء تجاوز الفشل الإجباري:
| درج | وصف | هل من المتوقع أن يكون وقت تعطل التطبيق؟ |
|---|---|---|
| 1 | يتوقف الخادم الأساسي بعد فترة وجيزة من تلقي طلب تجاوز الفشل. | Yes |
| 2 | يواجه التطبيق وقت تعطل لأن الخادم الأساسي معطل. | Yes |
| 3 | يكتشف نظام المراقبة الداخلية الفشل ويبدأ تجاوز الفشل إلى خادم الاستعداد. | Yes |
| 4 | يدخل خادم الاستعداد وضع الاسترداد قبل ترقيته بالكامل كخادم مستقل. | Yes |
| 5 | تنتظر عملية تجاوز الفشل حتى يكتمل الاسترداد في وضع الاستعداد. | Yes |
| 6 | بمجرد تشغيل الخادم، تقوم العملية بتحديث سجل DNS بنفس اسم المضيف ولكنها تستخدم عنوان IP الخاص بالاستعداد. | Yes |
| 7 | يمكن للتطبيق إعادة الاتصال بالخادم الأساسي الجديد واستئناف العملية. | No |
| 8 | يتم إنشاء خادم الاستعداد في المنطقة المفضلة. | No |
| 9 | يبدأ خادم الاستعداد في استرداد السجلات (من Azure Blob) التي فاتها أثناء إنشائه. | No |
| 10 | يتم إنشاء حالة ثابتة بين الخادم الأساسي وخادم الاستعداد. | No |
| 11 | اكتملت عملية تجاوز الفشل القسري. | No |
يبدأ وقت تعطل التطبيق بعد الخطوة 1 ويستمر حتى انتهاء الخطوة 6. يتم تشغيل الخطوات الأخرى في الخلفية دون التأثير على عمليات كتابة التطبيق والالتزامات.
مهم
تتضمن عملية تجاوز الفشل من طرف إلى طرف (أ) الفشل في خادم الاستعداد بعد الفشل الأساسي و(ب) إنشاء خادم استعداد جديد في حالة ثابتة. نظرا لأن تطبيقك يتحمل وقت تعطل حتى يكتمل تجاوز الفشل في وضع الاستعداد، فقم بقياس وقت التوقف عن العمل من منظور التطبيق/العميل بدلا من عملية تجاوز الفشل الشاملة من طرف إلى طرف.
اعتبارات عند إجراء عمليات تجاوز الفشل القسري
يمكن أن يكون وقت التشغيل الإجمالي من طرف إلى طرف أطول من وقت التوقف الفعلي الذي يعاني منه التطبيق.
مهم
لاحظ دائما وقت التعطل من منظور التطبيق!
لا تقم بإجراء عمليات تجاوز الفشل الفورية والخلفية. انتظر لمدة 15-20 دقيقة على الأقل بين عمليات تجاوز الفشل، حتى يمكن إنشاء خادم الاستعداد الجديد بالكامل.
قم بإجراء تجاوز فشل إجباري خلال فترة نشاط منخفض لتقليل وقت التوقف عن العمل.
أفضل الممارسات لإحصائيات PostgreSQL بعد تجاوز الفشل
بعد تجاوز فشل PostgreSQL، يتضمن الحفاظ على الأداء الأمثل لقاعدة البيانات فهم الأدوار المميزة لجداول pg_statistic و pg_stat_* .
pg_statistic يخزن الجدول إحصائيات المحسن ، والتي تعتبر ضرورية لمخطط الاستعلام. تتضمن هذه الإحصائيات توزيعات البيانات داخل الجداول وتظل سليمة بعد تجاوز الفشل، ما يضمن أن مخطط الاستعلام يمكنه الاستمرار في تحسين تنفيذ الاستعلام بشكل فعال استنادا إلى معلومات توزيع البيانات التاريخية الدقيقة.
في المقابل ، تتم إعادة تعيين الجداول pg_stat_* ، التي تسجل إحصائيات النشاط مثل عدد عمليات المسح والمجموعات المقروءة والتحديثات عند تجاوز الفشل. مثال على مثل هذا الجدول هو pg_stat_user_tables، الذي يتعقب النشاط للجداول المعرفة من قبل المستخدم. تعكس إعادة التعيين هذه بدقة الحالة التشغيلية للمرحلة الأساسية الجديدة ولكنها تعني أيضا فقدان مقاييس النشاط التاريخية التي يمكن أن تعلم عملية التفريغ التلقائي والكفاءات التشغيلية الأخرى.
بالنظر إلى هذا التمييز ، قم بالتشغيل ANALYZE بعد تجاوز فشل PostgreSQL. يحدث 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، ويمكن أن تتأخر عن الأساسي. تدعم طبقات الحوسبة المحسنة للأغراض العامة والذاكرة النسخ المتماثلة للقراءة.
لمزيد من المعلومات حول ميزات واعتبارات قراءة النسخ المتماثلة، راجع قراءة النسخ المتماثلة.
الكشف عن الانقطاع والإعلام والإدارة
إذا قمت بتكوين الخادم الخاص بك باستخدام النسخ الاحتياطي المتكرر جغرافيا، فيمكنك إجراء الاستعادة الجغرافية في المنطقة المقترنة. يتم توفير خادم جديد واسترداده إلى آخر البيانات المتوفرة التي تم نسخها إلى هذه المنطقة.
يمكنك أيضا استخدام النسخ المتماثلة للقراءة عبر المناطق. في حالة حدوث فشل في المنطقة، يمكنك إجراء عملية التعافي من الكوارث عن طريق ترقية النسخة المتماثلة للقراءة لتكون خادما مستقلا قابلا للقراءة والكتابة. من المتوقع أن يصل RPO إلى 5 دقائق (من الممكن فقدان البيانات) إلا في حالة حدوث فشل إقليمي شديد عندما يمكن أن يكون RPO قريبا من تأخر النسخ المتماثل في وقت الفشل.
لمزيد من المعلومات حول التخفيف من حدة وقت التعطل غير المخطط له والتعافي بعد الكارثة الإقليمية، راجع التخفيف من وقت التعطل غير المخطط له.