نظرة عامة على استمرارية الأعمال مع قاعدة بيانات Azure لـ PostgreSQL - خادم مرن

ينطبق على: قاعدة بيانات Azure ل PostgreSQL - خادم مرن

تشير استمرارية الأعمال في خادم Azure Database for PostgreSQL المرن إلى الآليات والسياسات والإجراءات التي تمكن عملك من مواصلة العمل في مواجهة التعطيل، لا سيما البنية الأساسية للحوسبة الخاصة به. في معظم الحالات، يعالج خادم Azure Database for PostgreSQL المرن الأحداث المعطلة التي قد تحدث في بيئة السحابة والحفاظ على تشغيل التطبيقات والعمليات التجارية. ومع ذلك، هناك بعض الأحداث التي لا يمكن معالجتها تلقائيا مثل:

  • يحذف أو يحدث المستخدم بطريق الخطأ صفاً في جدول.
  • يتسبب الزلزال في انقطاع التيار الكهربائي وتعطيل منطقة توفر أو منطقة مؤقتا.
  • تصحيح قاعدة البيانات المطلوب لإصلاح خطأ أو مشكلة أمان.

يوفر خادم Azure Database for PostgreSQL المرن ميزات تحمي البيانات وتخفف من وقت التعطل لقواعد البيانات المهمة أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها. استنادا إلى البنية الأساسية ل Azure التي توفر مرونة وتوافرا قويا، تحتوي قاعدة بيانات Azure لخادم PostgreSQL المرن على ميزات استمرارية الأعمال التي توفر حماية أخرى من الأخطاء، وتعالج متطلبات وقت الاسترداد، وتقلل من التعرض لفقدان البيانات. أثناء تصميم التطبيقات الخاصة بك، يجب مراعاة التسامح مع وقت التعطل - هدف وقت الاسترداد (RTO)، والتعرض لفقدان البيانات - هدف نقطة الاسترداد (RPO). على سبيل المثال، تتطلب قاعدة البيانات المهمة للأعمال وقت تشغيل أكثر صرامة من قاعدة بيانات الاختبار.

يوضح الجدول أدناه الميزات التي يوفرها خادم Azure Database for PostgreSQL المرن.

الميزة الوصف الاعتبارات
النسخ الاحتياطي التلقائي: يقوم خادم Azure Database for PostgreSQL المرن تلقائيا بإجراء نسخ احتياطية يومية لملفات قاعدة البيانات الخاصة بك ونسخ سجلات المعاملات احتياطيا باستمرار. يمكن الاحتفاظ بالنسخ الاحتياطية من 7 أيام حتى 35 يوماً. يمكنك استعادة خادم قاعدة البيانات إلى أي نقطة زمنية خلال فترة الاحتفاظ بالنسخ الاحتياطي. يعتمد هدف وقت الاسترداد على حجم البيانات التي ستتم استعادتها + الوقت لتنفيذ استرداد السجل. يمكن أن يكون من بضع دقائق حتى 12 ساعة. لمزيد من التفاصيل، راجع Concepts - النسخ الاحتياطي والاستعادة. تظل بيانات النسخ الاحتياطي داخل المنطقة.
توفر مرتفع متكرر في المنطقة يمكن نشر خادم Azure Database for PostgreSQL المرن بتكوين قابلية وصول عالية زائدة عن الحاجة للمنطقة حيث يتم نشر الخوادم الأساسية وخوادم الاستعداد في منطقتين مختلفتين من مناطق التوفر داخل المنطقة. يحمي تكوين قابلية الوصول العالية قواعد البيانات من حالات الفشل على مستوى المنطقة ويساعد أيضاً في تقليل وقت توقف التطبيق أثناء أحداث التوقف المخطط لها وغير المخطط لها. يتم نسخ البيانات من الخادم الأساسي إلى النسخة المتماثلة الاحتياطية في وضع متزامن. في حال حدوث أي تعطيل للخادم الأساسي، يتم فشل الخادم تلقائياً إلى النسخة المتماثلة الاحتياطية. من المتوقع أن يكون هدف وقت الاسترداد في معظم الحالات أقل من 120 ثانية. من المتوقع أن يكون هدف نقطة الاسترداد صفراً (لا يوجد فقدان للبيانات). لمزيد من المعلومات، راجع Concepts - قابلية الوصول العالية. مدعوم في مستويات الحوسبة المحسنة للأغراض العامة والذاكرة. لا يتوفر إلا في المناطق التي تتوفر فيها مناطق متعددة.
نفس قابلية الوصول العالية للمنطقة يمكن نشر خادم Azure Database for PostgreSQL المرن بنفس تكوين قابلية الوصول العالية للمنطقة (HA) حيث يتم نشر الخوادم الأساسية والخوادم الاحتياطية في نفس منطقة التوفر في المنطقة. وهذا يحمي من حالات التعطل على مستوى المنطقة، كما يساعد في تقليل وقت تعطل التطبيق أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها. يتم نسخ البيانات من الخادم الأساسي إلى النسخة المتماثلة الاحتياطية في وضع متزامن. في حال حدوث أي تعطيل للخادم الأساسي، يتم فشل الخادم تلقائياً إلى النسخة المتماثلة الاحتياطية. من المتوقع أن يكون هدف وقت الاسترداد في معظم الحالات أقل من 120 ثانية. من المتوقع أن يكون هدف نقطة الاسترداد صفراً (لا يوجد فقدان للبيانات). لمزيد من المعلومات، راجع Concepts - قابلية الوصول العالية. مدعوم في مستويات الحوسبة المحسنة للأغراض العامة والذاكرة.
أقراص مُدارة مميزة يتم تخزين ملفات قاعدة البيانات في تخزين عالي التحمل وموثوق به ومدار بشكل مميز. يوفر هذا التكرار البيانات مع ثلاث نسخ من النسخ المتماثلة المخزنة داخل منطقة توفر مع قدرات استرداد البيانات التلقائي. لمزيد من المعلومات، راجع وثائق الأقراص المدارة. البيانات المخزنة داخل منطقة توفر.
النسخ الاحتياطي المتكرر للمنطقة يتم تخزين النسخ الاحتياطية لخادم Azure Database for PostgreSQL المرن تلقائيا وآمنا في مساحة تخزين زائدة عن الحاجة داخل منطقة ما، إذا كانت المنطقة تدعم مناطق التوفر. أثناء الفشل على مستوى المنطقة حيث يتم توفير الخادم الخاص بك، وإذا لم يتم تكوين الخادم الخاص بك مع تكرار المنطقة، فلا يزال بإمكانك استعادة قاعدة البيانات باستخدام أحدث نقطة استعادة في منطقة مختلفة. لمزيد من المعلومات، راجع Concepts - Backup and Restore. ينطبق فقط في المناطق التي تتوفر فيها مناطق متعددة.
النسخ الاحتياطي المكرر جغرافياً يتم نسخ النسخ الاحتياطية لخادم Azure Database for PostgreSQL المرن إلى منطقة بعيدة. يساعد في وضع التعافي من الكوارث في حالة تعطل منطقة الخادم الأساسي. هذه الميزة ممكنة حالياً في مناطق محددة. يستغرق الأمر هدف وقت استرداد أطول وهدف نقطة استرداد أعلى اعتماداً على حجم البيانات التي ستتم استعادتها ومقدار الاسترداد لتنفيذه.
القراءة الخاصة بالنسخة المتماثلة يمكن نشر النسخ المتماثلة للقراءة عبر المناطق لحماية قواعد البيانات الخاصة بك من حالات الفشل على مستوى المنطقة. يتم تحديث النسخ المتماثلة للقراءة بشكل غير متزامن باستخدام تقنية النسخ المتماثل المادي لـ PostgreSQL، وقد تتأخر عن النسخة الأساسية. لمزيد من المعلومات، راجع المفاهيم - قراءة النسخ المتماثلة. مدعوم في مستويات الحوسبة المحسنة للأغراض العامة والذاكرة.

يقارن الجدول التالي RTO وRPO في سيناريو حمل العمل النموذجي:

الإمكانية مندفع الغرض العام الذاكرة المحسنة
استرداد في نقطة زمنية من النسخة الاحتياطية أي نقطة استعادة خلال فترة الاستبقاء
RTO - يختلف
RPO < 15 دقيقة
أي نقطة استعادة خلال فترة الاستبقاء
RTO - يختلف
RPO < 15 دقيقة
أي نقطة استعادة خلال فترة الاستبقاء
RTO - يختلف
RPO < 15 دقيقة
الاستعادة الجغرافية من النسخ الاحتياطية التي تم نسخها جغرافيًا RTO - يختلف
RPO < 1 ساعة
RTO - يختلف
RPO < 1 ساعة
RTO - يختلف
RPO < 1 ساعة
قراءة النسخ المتماثلة RTO - دقائق*
RPO < 5 دقائق*
RTO - دقائق*
RPO < 5 دقائق*
RTO - دقائق*
RPO < 5 دقائق*

* يمكن أن يكون RTO وRPO أعلى بكثير في بعض الحالات اعتماداً على عوامل مختلفة، بما في ذلك زمن الانتقال بين المواقع، وكمية البيانات التي سيتم إرسالها، والأهم من ذلك حمل عمل كتابة قاعدة البيانات الأساسية.

أحداث وقت التعطل المخطط لها

فيما يلي بعض سيناريوهات الصيانة المخطط لها. عادة ما تتكبد هذه الأحداث ما يصل إلى بضع دقائق من وقت التعطل، ودون فقدان البيانات.

السيناريو العملية
تحجيم الحساب (يبدأه المستخدم) أثناء عملية تحجيم الحساب، يسمح باكتمال نقاط التحقق النشطة، ويتم استنزاف اتصالات العميل، وإلغاء أي معاملات غير ملتزم بها، وفصل التخزين، ثم إيقاف تشغيله. يتم توفير مثيل خادم مرن جديد لقاعدة بيانات Azure ل PostgreSQL بنفس اسم خادم قاعدة البيانات بتكوين الحساب المتدرج. ثم يتم إرفاق التخزين بالخادم الجديد ويتم بدء تشغيل قاعدة البيانات التي تقوم بإجراء الاسترداد، إذا لزم الأمر، قبل قبول اتصالات العميل.
توسيع نطاق التخزين (يبدأه المستخدم) عند بدء عملية تخزين توسيع النطاق، يسمح باكتمال نقاط التحقق النشطة، ويتم استنزاف اتصالات العميل، ويتم إلغاء أي معاملات غير ملتزم بها. بعد ذلك يتم إيقاف تشغيل الخادم. يتم تغيير حجم التخزين إلى الحجم المطلوب ثم إرفاقه بالخادم الجديد. يتم إجراء الاسترداد إذا لزم الأمر قبل قبول اتصالات العميل. لاحظ أن تقليص حجم التخزين غير مدعوم.
نشر البرامج الجديدة (تبدأه Azure) يحدث إطلاق الميزات الجديدة أو إصلاحات الأخطاء تلقائياً كجزء من الصيانة المخطط لها للخدمة، ويمكنك جدولة وقت حدوث هذه الأنشطة. لمزيد من المعلومات، تحقق من المدخل الخاص بك.
ترقيات الإصدار الثانوي (تبدأها Azure) تقوم قاعدة بيانات Azure لـ PostgreSQL بشكل تلقائي بتصحيح خوادم قاعدة البيانات إلى الإصدار الثانوي الذي يحدده Azure. يحدث ذلك كجزء من الصيانة المخطط لها للخدمة. تتم إعادة تشغيل خادم قاعدة البيانات تلقائياً باستخدام الإصدار الثانوي الجديد. لمزيد من المعلومات، انظر الوثائق. يمكنك أيضاً التحقق من المدخل لديك.

عند تكوين مثيل خادم Azure Database for PostgreSQL المرن بتوافر عال، تقوم الخدمة بإجراء عمليات التحجيم والصيانة على الخادم الاحتياطي أولا. لمزيد من المعلومات، راجع Concepts - قابلية الوصول العالية.

التخفيف غير المخطط له من وقت التعطل.

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

على الرغم من أننا نسعى باستمرار لتوفير قابلية وصول عالية، هناك أوقات تتسبب فيها قاعدة بيانات Azure لخادم PostgreSQL المرن في انقطاع يتسبب في عدم توفر قواعد البيانات وبالتالي التأثير على تطبيقك. عندما تكتشف مراقبة الخدمة الخاصة بنا المشكلات التي تسبب أخطاء اتصال أو فشلا أو مشكلات في الأداء على نطاق واسع، تعلن الخدمة تلقائيا عن انقطاع لإبقائها على اطلاع.

انقطاع الخدمة

في حالة انقطاع خادم Azure Database for PostgreSQL المرن، يمكنك مشاهدة المزيد من التفاصيل المتعلقة بالانقطاع في الأماكن التالية:

  • شعار مدخل Azure: إذا تم تحديد اشتراكك ليتأثر، فسيكون هناك تنبيه بانقطاع مشكلة الخدمة في إعلامات مدخل Microsoft Azure.

 لقطة شاشة تعرض الإعلامات في مدخل Microsoft Azure.

  • تعليمات + دعم أو دعم + استكشاف الأخطاء وإصلاحها: عند إنشاء تذكرة دعم من التعليمات + الدعم أو الدعم + استكشاف الأخطاء وإصلاحها، ستكون هناك معلومات حول أي مشكلات تؤثر على مواردك. حدد عرض تفاصيل الانقطاع للحصول على مزيد من المعلومات وملخص التأثير. سيكون هناك أيضا تنبيه في صفحة طلب دعم جديد.

 لقطة شاشة تعرض إعلامات دعم التعليمات في مدخل Microsoft Azure.

  • تعليمات الخدمة: تحتوي صفحة حالة الخدمة في مدخل Microsoft Azure على معلومات حول حالة مركز بيانات Azure عالميا. ابحث عن "حالة الخدمة" في شريط البحث في مدخل Microsoft Azure، ثم اعرض مشكلات الخدمة في فئة الأحداث النشطة. يمكنك أيضا عرض صحة الموارد الفردية في صفحة صحة الموارد لأي مورد ضمن قائمة التعليمات. فيما يلي لقطة شاشة نموذجية لصفحة حالة الخدمة، مع معلومات حول مشكلة خدمة نشطة في جنوب شرق آسيا.

 لقطة شاشة تعرض انقطاع الخدمة في مدخل Service Health.

  • إشعار البريد الإلكتروني: إذا قمت بإعداد التنبيهات، فسيصل إشعار بالبريد الإلكتروني عندما يؤثر انقطاع الخدمة على اشتراكك وموردك. تصل رسائل البريد الإلكتروني من "azure-noreply@microsoft.com". يبدأ نص البريد الإلكتروني ب "تنبيه سجل النشاط ... تم تشغيل بواسطة مشكلة خدمة لاشتراك Azure...". لمزيد من المعلومات حول تنبيهات حالة الخدمة، راجع تلقي تنبيهات سجل النشاط على إعلامات خدمة Azure باستخدام مدخل Microsoft Azure.

هام

كما يوحي الاسم، يتم استخدام مساحات الجداول المؤقتة في PostgreSQL للكائنات المؤقتة، بالإضافة إلى عمليات قاعدة البيانات الداخلية الأخرى، مثل الفرز. لذلك لا نوصي بإنشاء كائنات مخطط المستخدم في مساحة الجدول المؤقتة، لأننا لا نضمن متانة مثل هذه الكائنات بعد إعادة تشغيل الخادم، وتجاوز فشل HA، وما إلى ذلك.

وقت التعطل غير المخطط له: سيناريوهات الأعطال واسترداد الخدمة

فيما يلي بعض سيناريوهات التعطل غير المخطط لها وعملية الاسترداد.

السيناريو عملية الاسترداد
[الخوادم التي تم تكوينها دون قابلية وصول عالية زائدة عن الحاجة في المنطقة]
عملية الاسترداد
[الخوادم التي تم تكوينها باستخدام قابلية الوصول العالية المكررة في المنطقة]
فشل خادم قاعدة البيانات إذا كان خادم قاعدة البيانات متوقفاً عن التشغيل، فسيحاول Azure إعادة تشغيل خادم قاعدة البيانات. إذا فشل ذلك، فستتم إعادة تشغيل خادم قاعدة البيانات على عقدة فعلية أخرى.

يعتمد وقت الاسترداد (RTO) على عوامل مختلفة بما في ذلك النشاط في وقت الخطأ، مثل المعاملة الكبيرة، وحجم الاسترداد الذي سيتم تنفيذه أثناء عملية بدء تشغيل خادم قاعدة البيانات.

تحتاج التطبيقات التي تستخدم قواعد بيانات PostgreSQL إلى أن تُنشئ بطريقة تكتشف وتعيد محاولة الاتصالات المنقطعة والمعاملات الفاشلة.
إذا تم الكشف عن فشل خادم قاعدة البيانات، يتم توافق الخادم إلى الخادم الاحتياطي، وبالتالي تقليل وقت التعطل. لمزيد من المعلومات، راجع صفحة مفاهيم قابلية وصول عالية. من المتوقع أن يكون هدف وقت الاسترداد من 60 إلى 120 ثانية، دون خسارة للبيانات.
فشل التخزين لا ترى التطبيقات أي تأثير لأي مشكلات متعلقة بالتخزين مثل فشل القرص أو تلف الكتلة الفعلية. نظراً لتخزين البيانات في 3 نسخ، يتم تقديم نسخة البيانات من خلال التخزين المتبقي. يتم إصلاح كتلة البيانات التالفة تلقائياً ويتم إنشاء نسخة جديدة من البيانات تلقائياً. بالنسبة لأي أخطاء نادرة وغير قابلة للاسترداد مثل التخزين بأكمله غير قابل للوصول، فشل مثيل خادم Azure Database for PostgreSQL المرن في النسخة المتماثلة الاحتياطية لتقليل وقت التعطل. لمزيد من المعلومات، راجع صفحة مفاهيم قابلية وصول عالية.
أخطاء منطقية/أخطاء المستخدم للتعافي من أخطاء المستخدم، مثل الجداول التي تم إسقاطها عن طريق الخطأ أو البيانات المحدثة بشكل غير صحيح، يجب عليك إجراء استرداد في نقطة زمنية (PITR). أثناء تنفيذ عملية الاستعادة، يمكنك تحديد نقطة الاستعادة المخصصة، وهي الوقت المناسب قبل حدوث الخطأ.

إذا كنت تريد استعادة مجموعة فرعية فقط من قواعد البيانات أو جداول محددة بدلاً من كافة قواعد البيانات في خادم قاعدة البيانات، يمكنك استعادة خادم قاعدة البيانات في مثيل جديد، وتصدير الجدول (الجداول) عبر pg_dump، ثم استخدام pg_restore لاستعادة تلك الجداول في قاعدة البيانات الخاصة بك.
أخطاء المستخدم هذه غير محمية بتوافر عال حيث يتم نسخ جميع التغييرات إلى النسخة المتماثلة الاحتياطية بشكل متزامن. يجب عليك إجراء استعادة في نقطة زمنية للتعافي من مثل هذه الأخطاء.
فشل منطقة قابلية الوصول للاسترداد من فشل على مستوى المنطقة، يمكنك إجراء استعادة في نقطة زمنية باستخدام النسخ الاحتياطي واختيار نقطة استعادة مخصصة مع أحدث وقت لاستعادة أحدث البيانات. يتم نشر مثيل خادم مرن جديد لقاعدة بيانات Azure ل PostgreSQL في منطقة أخرى غير متأثرة. يعتمد الوقت المستغرق للاستعادة على النسخ الاحتياطي السابق وحجم سجلات المعاملات للاسترداد. فشل خادم Azure Database for PostgreSQL المرن تلقائيا إلى خادم الاستعداد في غضون 60-120s دون فقدان البيانات. لمزيد من المعلومات، راجع صفحة مفاهيم قابلية وصول عالية.
فشل المنطقة إذا تم تكوين الخادم الخاص بك باستخدام نسخة احتياطية جغرافية مكررة، يمكنك إجراء استعادة جغرافية في المنطقة المقترنة. سيتم توفير خادم جديد واسترداده إلى آخر البيانات المتوفرة التي تم نسخها إلى هذه المنطقة.

يمكنك أيضا استخدام النسخ المتماثلة للقراءة عبر المناطق. في حالة فشل المنطقة، يمكنك تنفيذ عملية التعافي من الكوارث عن طريق ترقية النسخة المتماثلة للقراءة لتكون خادما مستقلا قابلا للقراءة والكتابة. من المتوقع أن يصل هدف نقطة الاسترداد إلى 5 دقائق (فقدان البيانات المحتمل) إلا في حالة الفشل الإقليمي الحاد عندما يمكن أن يكون RPO قريبا من تأخر النسخ المتماثل في وقت الفشل.
نفس العملية.

تكوين قاعدة البيانات بعد الاسترداد من الفشل الإقليمي

هام

يمكن استعادة الخوادم المحذوفة. إذا قمت بحذف الخادم، يمكنك اتباع إرشاداتنا استعادة قاعدة بيانات Azure التي تم إسقاطها - قاعدة بيانات Azure ل PostgreSQL - الخادم المرن للاسترداد. نوصي باستخدام تأمين مورد Azure للمساعدة في منع الحذف العرضي للخادم الخاص بك.

الخطوات التالية