مفاهيم التوفر العالي في قاعدة بيانات Azure ل PostgreSQL - خادم مرن

  • مقالة
  • قراءة خلال 20 دقائق

قاعدة بيانات Azure ل PostgreSQL - يوفر الخادم المرن تكوينا عالي التوافر مع إمكانية تجاوز الفشل التلقائي باستخدام نشر الخادم المتكرر للمنطقة . عند النشر في تكوين متكرر للمنطقة، يقوم الخادم المرن تلقائيا بتوفير نسخة متماثلة احتياطية وإدارتها في منطقة توافر خدمات مختلفة. باستخدام النسخ المتماثل دفق PostgreSQL ، يتم نسخ البيانات إلى خادم النسخ المتماثل في وضع الاستعداد في الوضع المتزامن .

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

zone redundant high availability

بنية التوفر العالي الزائدة عن الحاجة في المنطقة

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

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

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

تتم مراقبة سلامة الخوادم الأساسية والاحتياطية باستمرار ويتم اتخاذ الإجراءات المناسبة لمعالجة المشكلات بما في ذلك تشغيل تجاوز الفشل إلى خادم الاستعداد. يتم سرد حالات التوافر العالي الزائدة عن الحاجة في المنطقة أدناه:

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

ملاحظة

يمكنك تمكين التوافر العالي أثناء إنشاء الخادم أو في وقت لاحق أيضا. إذا كنت تقوم بتمكين أو تعطيل التوافر العالي أثناء مرحلة ما بعد الإنشاء، فمن المستحسن إجراء العملية عندما يكون نشاط الخادم الأساسي منخفضا.

عمليات الدولة الثابتة

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

zone redundant high availability - steady state

  1. يتصل العملاء بالخادم المرن ويقومون بإجراء عمليات الكتابة.
  2. يتم نسخ التغييرات إلى موقع الاستعداد.
  3. الابتدائية يتلقى الإقرار.
  4. يتم الاعتراف بالكتابات / الالتزامات.

عملية تجاوز الفشل - أوقات التوقف المخطط لها

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

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

تقليل وقت التوقف المخطط له من خلال نافذة الصيانة المدارة

باستخدام الخادم المرن، يمكنك اختياريا جدولة أنشطة الصيانة التي بدأها Azure عن طريق اختيار نافذة مدتها 60 دقيقة في يوم تفضله حيث من المتوقع أن تكون الأنشطة الموجودة على قواعد البيانات منخفضة. ستحدث مهام صيانة Azure مثل التصحيح أو ترقيات الإصدارات الثانوية خلال نافذة الصيانة هذه. إذا لم تختر نافذة مخصصة، اختيار نافذة مخصصة لمدة 1 ساعة للنظام بين الساعة 11 مساء و7 صباحا بالتوقيت المحلي لخادمك.

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

عملية تجاوز الفشل - أوقات التوقف غير المخطط لها

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

ملاحظة

توفر الخوادم المرنة التي تم تكوينها مع توفر عال زائد عن الحاجة في المنطقة هدفا لنقطة الاسترداد (RPO) يساوي صفرا (بدون فقدان البيانات). من المتوقع أن يكون هدف وقت الاسترداد (RTO) أقل من 120s في الحالات النموذجية. ومع ذلك، اعتمادا على النشاط في خادم قاعدة البيانات الأساسي في وقت تجاوز الفشل، قد يستغرق تجاوز الفشل وقتا أطول.

بعد تجاوز الفشل، أثناء توفير خادم استعداد جديد، لا يزال بإمكان التطبيقات الاتصال بالخادم الأساسي ومتابعة عمليات القراءة/الكتابة الخاصة بها. بمجرد إنشاء خادم الاستعداد ، سيبدأ في استرداد السجلات التي تم إنشاؤها بعد تجاوز الفشل.

zone redundant high availability - failover

  1. خادم قاعدة البيانات الأساسي معطل ويفقد العملاء اتصال قاعدة البيانات.
  2. يتم تنشيط خادم الاستعداد ليصبح الخادم الأساسي الجديد. يتصل العميل بالخادم الأساسي الجديد باستخدام نفس سلسلة الاتصال. وجود تطبيق العميل في نفس المنطقة مثل خادم قاعدة البيانات الأساسي يقلل من زمن الوصول ويحسن الأداء.
  3. يتم إنشاء خادم الاستعداد في نفس المنطقة مثل الخادم الأساسي القديم ويتم بدء النسخ المتماثل الدفق.
  4. بمجرد إنشاء النسخ المتماثل للحالة الثابتة، يلتزم تطبيق العميل ويتم الاعتراف بالكتابة بعد استمرار البيانات على كلا الموقعين.

تجاوز الفشل عند الطلب

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

تجاوز الفشل القسري

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

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

فيما يلي الخطوات أثناء تجاوز الفشل القسري:

الخطوة الوصف هل من المتوقع تعطل التطبيق؟
1 يتم إيقاف الخادم الأساسي بعد وقت قصير من استلام طلب تجاوز الفشل. نعم
2 يواجه التطبيق وقت توقف عن العمل حيث أن الخادم الأساسي معطل. نعم
3 يكتشف نظام المراقبة الداخلية الفشل ويبدأ تجاوز الفشل إلى خادم الاستعداد. نعم
4 يدخل خادم الاستعداد في وضع الاسترداد قبل أن تتم ترقيته بالكامل كخادم مستقل. نعم
5 تنتظر عملية تجاوز الفشل اكتمال استرداد الاستعداد. نعم
6 بمجرد تشغيل الخادم ، يتم تحديث سجل DNS بنفس اسم المضيف ، ولكن باستخدام عنوان IP الخاص بالاستعداد. نعم
7 يمكن للتطبيق إعادة الاتصال بالخادم الأساسي الجديد واستئناف العملية. لا
8 يتم إنشاء خادم استعداد في المنطقة المفضلة. لا
9 يبدأ خادم الاستعداد في استرداد السجلات (من Azure BLOB) التي فاته أثناء إنشائه. لا
10 يتم إنشاء حالة ثابتة بين الخادم الأساسي وخادم الاستعداد. لا
11 اكتملت عملية تجاوز الفشل القسري. لا

من المتوقع أن يبدأ وقت تعطل التطبيق بعد الخطوة #1 ويستمر حتى تكتمل الخطوة #6. تحدث بقية الخطوات في الخلفية دون التأثير على عمليات كتابة التطبيق والتزامه.

هام

تتضمن عملية تجاوز الفشل من طرف إلى طرف (أ) الفشل في خادم الاستعداد بعد الفشل الأساسي و (ب) إنشاء خادم استعداد جديد في حالة ثابتة. نظرا لأن تطبيقك يتحمل وقت توقف عن العمل فقط حتى يكتمل تجاوز الفشل إلى وضع الاستعداد، يرجى قياس وقت التوقف عن العمل من منظور التطبيق/العميل بدلا من عملية تجاوز الفشل الشاملة من البداية إلى النهاية.

تجاوز الفشل المخطط له

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

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

الخطوة الوصف هل من المتوقع تعطل التطبيق؟
1 انتظر حتى يتم القبض على خادم الاستعداد مع الأساسي. لا
2 يبدأ نظام المراقبة الداخلية سير عمل تجاوز الفشل. لا
3 يتم حظر عمليات كتابة التطبيق عندما يكون خادم الاستعداد قريبا من رقم تسلسل السجل الأساسي (LSN). نعم
4 تتم ترقية خادم الاستعداد ليكون خادما مستقلا. نعم
5 يتم تحديث سجل DNS باستخدام عنوان IP الخاص بخادم الاستعداد الجديد. نعم
6 تطبيق لإعادة الاتصال واستئناف القراءة / الكتابة مع أساسي جديد لا
7 يتم إنشاء خادم استعداد جديد في منطقة أخرى. لا
8 يبدأ خادم الاستعداد في استرداد السجلات (من Azure BLOB) التي فاته أثناء إنشائه. لا
9 يتم إنشاء حالة ثابتة بين الخادم الأساسي وخادم الاستعداد. لا
10 اكتملت عملية تجاوز الفشل المخطط لها. لا

يبدأ وقت تعطل التطبيق في الخطوة #3 ويمكن استئناف العملية بعد الخطوة #5. تحدث بقية الخطوات في الخلفية دون التأثير على عمليات كتابة التطبيق والتزامه.

الاعتبارات أثناء تنفيذ عمليات تجاوز الفشل عند الطلب

  • قد ينظر إلى وقت التشغيل الإجمالي من البداية إلى النهاية لفترة أطول من وقت التوقف الفعلي الذي يمر به التطبيق. يرجى ملاحظة وقت التوقف عن العمل من منظور التطبيق.
  • يرجى عدم إجراء عمليات تجاوز فشل فورية ومتتالية. انتظر لمدة 15-20 دقيقة على الأقل بين عمليات تجاوز الفشل ، مما سيسمح بإنشاء خادم الاستعداد الجديد بالكامل.
  • بالنسبة لتجاوز الفشل المخطط له مع تقليل وقت التوقف عن العمل ، يوصى بالأداء خلال فترة النشاط المنخفض.

راجع هذا الدليل لإدارة التوافر العالي.

استعادة في الوقت المناسب لخوادم HA

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

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

توفر عالي متكرر للمنطقة - الميزات

  • سيتم نشر النسخة المتماثلة الاحتياطية في تكوين VM دقيق مثل الخادم الأساسي ، بما في ذلك vCores والتخزين وإعدادات الشبكة (VNET وجدار الحماية) وما إلى ذلك.

  • يمكنك إضافة توفر عال لخادم قاعدة بيانات موجود.

  • يمكنك إزالة النسخة المتماثلة في وضع الاستعداد عن طريق تعطيل التوافر العالي.

  • يمكنك فقط اختيار منطقة توافر الخدمات لخادم قاعدة البيانات الأساسي. يتم تحديد منطقة الاستعداد تلقائيا.

  • يتم تنفيذ عمليات مثل الإيقاف والبدء وإعادة التشغيل على كل من خوادم قاعدة البيانات الأساسية والاحتياطية في نفس الوقت.

  • يتم إجراء النسخ الاحتياطي التلقائي من خادم قاعدة البيانات الأساسي وتخزينها في منطقة تخزين زائدة عن الحاجة.

  • يتصل العملاء دائما باسم المضيف النهائي لخادم قاعدة البيانات الأساسي.

  • يتم تطبيق أي تغييرات على معلمات الخادم على النسخة المتماثلة في وضع الاستعداد أيضا.

  • القدرة على إعادة تشغيل الخادم لالتقاط أي تغييرات ثابتة في معلمة الخادم.

  • تحدث أنشطة الصيانة الدورية مثل ترقيات الإصدار الطفيفة في وضع الاستعداد أولا ويتم فشل الخدمة لتقليل وقت التوقف.

توفر عالي زائد عن الحاجة في المنطقة - قيود

  • التوفر العالي غير مدعوم بطبقة حوسبة قابلة للانفجار.

  • يتم دعم التوافر العالي فقط في المناطق التي تتوفر فيها مناطق متعددة.

  • نظرا للنسخ المتماثل المتزامن إلى منطقة توافر خدمات أخرى، يمكن للتطبيقات تجربة الكتابة المرتفعة والالتزام بزمن الوصول.

  • لا يمكن استخدام النسخة المتماثلة في وضع الاستعداد لاستعلامات القراءة.

  • اعتمادا على عبء العمل والنشاط على الخادم الأساسي، قد تستغرق عملية تجاوز الفشل وقتا أطول من 120 ثانية بسبب الاسترداد المتضمن في النسخة المتماثلة الاحتياطية قبل أن يمكن الترويج لها.

  • عادة ما يقوم خادم الاستعداد باسترداد ملفات WAL بمعدل 40 ميجابايت / ثانية. إذا تجاوز عبء العمل هذا الحد، فقد تواجه وقتا ممتدا لإكمال عملية الاسترداد إما أثناء تجاوز الفشل أو بعد إنشاء وضع استعداد جديد.

  • إعادة تشغيل خادم قاعدة البيانات الأساسي أيضا إعادة تشغيل النسخ المتماثلة الاستعداد.

  • تكوين النسخ المتماثلة للقراءة الإضافية غير مدعوم.

  • لا يمكن جدولة تكوين مهام الإدارة التي بدأها العميل أثناء نافذة الصيانة المدارة.

  • تحدث الأحداث المخطط لها مثل حوسبة المقياس وتخزين المقياس في وضع الاستعداد أولا ثم على الخادم الأساسي. حاليا لا يفشل الخادم في هذه العمليات المخطط لها.

  • إذا تم تكوين فك التشفير المنطقي أو النسخ المتماثل المنطقي باستخدام خادم مرن مكون من HA، في حالة تجاوز الفشل إلى خادم الاستعداد، لا يتم نسخ فتحات النسخ المتماثل المنطقي إلى خادم الاستعداد.

التوفر بدون منطقة HA زائدة عن الحاجة

بالنسبة للخوادم المرنة التي تم تكوينها بدون توفر عال زائد عن الحاجة في المنطقة، لا تزال الخدمة توفر التوافر المضمن وتكرار التخزين والمرونة للمساعدة في التعافي من أي أحداث توقف مخطط لها أو غير مخطط لها.

Diagram that shows availability without zone redundant ha - steady state.

وقت التوقف المخطط له

فيما يلي بعض سيناريوهات الصيانة المخطط لها:

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

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

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

فيما يلي بعض سيناريوهات الفشل وكيفية استرداد الخادم المرن تلقائيا:

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

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

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

فيما يلي بعض سيناريوهات الفشل التي تتطلب إجراء المستخدم للاسترداد:

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

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

إذا كنت تريد استعادة مجموعة فرعية فقط من قواعد البيانات أو جداول معينة بدلا من كافة قواعد البيانات في خادم قاعدة البيانات، فيمكنك استعادة خادم قاعدة البيانات في مثيل جديد، وتصدير الجدول (الجداول) عبر pg_dump، ثم استخدام pg_restore لاستعادة هذه الجداول إلى قاعدة البيانات الخاصة بك.

الأسئلة المتداولة

أسئلة تكوين HA

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

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

  • ما هي طريقة النسخ المتماثل بين الخوادم الأساسية والخوادم؟
    يتم إنشاء الوضع المتزامن للنسخ المتماثل بين الخادم الأساسي والخادم. يتم الاعتراف بعمليات كتابة التطبيق والالتزام به فقط بعد استمرار بيانات سجل الكتابة مسبقا (WAL) على موقع الاستعداد. وهذا يتيح عدم فقدان البيانات في حالة تجاوز الفشل.

  • الوضع المتزامن يتكبد الكمون. ما نوع تأثير الأداء الذي يمكنني توقعه لطلبي؟
    يؤدي التكوين في HA إلى بعض الكمون للكتابة والالتزام. لا يوجد تأثير على قراءة الاستعلامات. يختلف تأثير الأداء وفقا لعبء العمل لديك. كمبدأ توجيهي عام ، يمكن أن يكون تأثير الكتابة والالتزام حوالي 20-30٪ من التأثير.

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

  • هل يمكنني تمكين HA أو تعطيله في أي وقت؟

    نعم. يمكنك تمكين HA الزائدة عن الحاجة أو تعطيلها في أي وقت إلا عندما يكون الخادم في حالات معينة مثل التوقف أو إعادة التشغيل أو بالفعل في طور الفشل.

  • هل يمكنني اختيار منطقة توافر الخدمات للاستعداد؟
    كلا. حاليا لا يمكنك اختيار AZ للاستعداد. ونخطط لإضافة تلك القدرة في المستقبل.

  • هل يمكنني تكوين HA بين الوصول الخاص (VNET) والوصول العام؟
    كلا. يمكنك إما تكوين HA داخل VNET (يمتد عبر مناطق توافر الخدمات داخل منطقة) أو الوصول العام.

  • هل يمكنني تكوين HA عبر المناطق؟
    كلا. يتم تكوين HA داخل منطقة، ولكن عبر مناطق توافر الخدمات. في المستقبل، نخطط لتقديم نسخ متماثلة للقراءة يمكن تكوينها عبر المناطق لأغراض التعافي من الكوارث (DR). سنقدم المزيد من التفاصيل عند تمكين الميزة.

  • هل يمكنني استخدام النسخ المتماثل المنطقي مع خوادم HA التي تم تكوينها؟
    يمكنك تكوين النسخ المتماثل المنطقي باستخدام HA. ومع ذلك، بعد تجاوز الفشل، لا يتم نسخ تفاصيل الفتحة المنطقية إلى وضع الاستعداد. وبالتالي ، هناك حاليا دعم محدود لهذا التكوين.

  • كيف يوفر الخادم المرن توافرا عاليا في حالة حدوث خطأ - مثل خطأ AZ؟
    عند تمكين الخادم باستخدام HA الزائدة عن الحاجة في المنطقة، يتم نشر نسخة متماثلة احتياطية فعلية بنفس تكوين الحوسبة والتخزين مثل الأساسي تلقائيا في منطقة توافر خدمات مختلفة عن المنطقة الأساسية. يتم إنشاء النسخ المتماثل دفق PostgreSQL بين الخوادم الأساسية والاستعداد.

  • ما هي عملية تجاوز الفشل النموذجية أثناء الانقطاع؟
    عندما يتم الكشف عن الخطأ بواسطة نظام المراقبة ، فإنه يبدأ سير عمل تجاوز الفشل الذي يتضمن التأكد من أن الاستعداد قد طبق جميع ملفات WAL المتبقية وتم القبض عليه بالكامل قبل فتح ذلك للقراءة / الكتابة. ثم يتم تحديث DNS بعنوان IP الخاص بالاستعداد قبل أن يتمكن العملاء من إعادة الاتصال بالخادم بنفس نقطة النهاية (اسم المضيف). يتم إنشاء وضع استعداد جديد للحفاظ على التكوين في وضع متوفر للغاية.

  • ما هو وقت تجاوز الفشل النموذجي وفقدان البيانات المتوقع أثناء الانقطاع؟
    في حالة نموذجية ، يتراوح وقت تجاوز الفشل أو وقت التوقف عن العمل الذي يواجهه منظور التطبيق بين 60s-120s. يمكن أن يكون هذا أطول في الحالات التي يتم فيها الانقطاع أثناء المعاملات طويلة الأمد أو إنشاء الفهرس أو أثناء أنشطة الكتابة الثقيلة - حيث قد يستغرق الاستعداد وقتا أطول لإكمال عملية الاسترداد.

    نظرا لأن النسخ المتماثل يحدث في الوضع المتزامن ، فلا يتوقع فقدان البيانات.

  • هل تقدمون اتفاقية مستوى الخدمة لوقت تجاوز الفشل؟
    بالنسبة لوقت تجاوز الفشل، نقدم إرشادات حول المدة التي تستغرقها العملية عادة. يتم توفير اتفاقية مستوى الخدمة الرسمية لوقت التشغيل الإجمالي.

  • هل يتصل التطبيق تلقائيا بالخادم بعد تجاوز الفشل؟
    كلا. يجب أن تحتوي التطبيقات على آلية إعادة المحاولة لإعادة الاتصال بنفس نقطة النهاية (اسم المضيف).

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

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

    من psql ، يمكنك التشغيل select * from pg_stat_replication; الذي يعرض حالة البث من بين تفاصيل أخرى.

  • هل تؤيد قراءة الاستعلامات على النسخة المتماثلة الاحتياطية؟
    كلا. نحن لا ندعم استعلامات القراءة على النسخة المتماثلة الاحتياطية.

  • عندما أقوم بالاسترداد في الوقت المحدد (PITR)، هل سيقوم تلقائيا بتكوين الخادم المستعاد في HA؟
    كلا. تتم استعادة خادم PITR كخادم مستقل. إذا كنت ترغب في تمكين HA ، فيمكنك القيام بذلك بعد اكتمال الاستعادة.

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