الموثوقية في قاعدة بيانات Azure لـ MySQL

قاعدة بيانات Azure لـ MySQL هي خدمة قاعدة بيانات مدارة بالكامل تمنحك التحكم الدقيق والمرونة في وظائف إدارة قاعدة البيانات وإعدادات التكوين. توفر الخدمة قابلية وصول عالية (HA) وقدرات التعافي من الكوارث (DR) بناء على متطلباتك.

عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.

توضح هذه المقالة كيفية جعل قاعدة بيانات Azure لـ MySQL مرنة في مواجهة حالات الانقطاع والمشاكل المحتملة المختلفة، بما في ذلك الأخطاء العابرة وانقطاعات منطقة التوفر وانقطاع المنطقة وصيانة الخدمة. كما يصف كيفية استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشكلات ويسلط الضوء على بعض المعلومات الرئيسية حول اتفاقية مستوى الخدمة قاعدة بيانات Azure لـ MySQL (SLA).

توصيات نشر الإنتاج

يوفر إطار عمل Azure Well-Architected توصيات عبر الموثوقية والأمان والتكلفة والعمليات والأداء. لفهم كيفية تأثير هذه المجالات على بعضها البعض والمساهمة في حل قاعدة بيانات Azure لـ MySQL موثوق به، راجع أفضل ممارسات البنية قاعدة بيانات Azure لـ MySQL.

نظرة عامة على بنية الموثوقية

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

البنية المنطقية

عند العمل مع قاعدة بيانات Azure لـ MySQL، يمكنك نشر خادم يمثل موارد الحوسبة والتخزين المطلوبة لدعم خادم قاعدة البيانات. يمكنك نشر قاعدة بيانات واحدة أو أكثر على الخادم.

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

لمزيد من المعلومات حول تصميم الخدمة العامة ونماذج التوزيع، راجع نظرة عامة على قاعدة بيانات Azure لـ MySQL.

العمارة المادية

• فصل الحوسبة والتخزين: يستخدم قاعدة بيانات Azure لـ MySQL بنية فصل الحوسبة والتخزين لدعم قابلية الوصول العالية. يعمل محرك قاعدة البيانات على جهاز ظاهري (VM). يتم تخزين ملفات البيانات في تخزين Azure، والتي تحتفظ بشكل متزامن بثلاث نسخ من البيانات للحماية من فشل أجهزة التخزين. اعتمادا على تكوين قابلية الوصول العالية للخادم، يمكن تخزين ملفات البيانات في تخزين المنطقة المكررة (ZRS) أو التخزين المحلي المكرر (LRS).

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

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

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

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

  لمزيد من المعلومات، راجع قابلية الوصول العالية في قاعدة بيانات Azure لـ MySQL.

• النسخ الاحتياطية: يقوم قاعدة بيانات Azure لـ MySQL تلقائيا بإنشاء نسخ احتياطية للخادم. لمزيد من المعلومات، راجع النسخ الاحتياطي والاستعادة.

المرونة في مواجهة الأعطال العابرة

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

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

يجب أن تعالج تطبيقاتك أخطاء الاتصال العابرة التي يمكن أن تحدث أثناء الصيانة أو عمليات التحجيم أو انقطاع الشبكة. اتبع هذه التوصيات:

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

• عندما يكون ذلك ممكنا، استخدم مكتبات العميل التي تتعامل تلقائيا مع عمليات إعادة المحاولة.

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

المرونة في مواجهة حالات فشل منطقة التوفر

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

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

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

يدعم قاعدة بيانات Azure لـ MySQL نوعين من تكوين منطقة التوفر عند استخدام HA:

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

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

  استخدم عمليات النشر المتكررة في المنطقة لخوادم الإنتاج.

  

  يتكون الرسم التخطيطي من ثلاثة أقسام. يسرد القسم الأول تطبيقات العميل مثل الأجهزة الظاهرية Azure خدمة Azure Kubernetes ‏(AKS) "Azure App Service". القسم التالي يسمى منطقة التوفر 1. يحتوي على الخادم الأساسي واثنين من الأقسام الفرعية، الحوسبة والتخزين، مفصولة بخط منقط. القسم الثالث يسمى منطقة التوفر 2. يعكس منطقة التوفر 1، ولكنه يحتوي على خادم الاستعداد. تشير الأسهم من تطبيقات العميل إلى موازن تحميل قياسي. يشير سهم واحد من موازن التحميل إلى جهاز ظاهري على الخادم الأساسي في منطقة التوفر 1. تقوم الأسهم ثنائية الاتجاه بتوصيل الجهاز الظاهري ومشاركة الملفات المتميزة ومحرك الأقراص ذي الحالة الصلبة (SSD). نقاط سهم أخرى من مشاركة الملفات المتميزة إلى تخزين كائن ثنائي كبير الحجم للنسخ الاحتياطي. سهم يسمى نقاط النسخ المتماثل غير المتزامنة المستندة إلى التخزين من منطقة التوفر 1 إلى منطقة التوفر 2.

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

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

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

  

  يتكون الرسم التخطيطي من ثلاثة أقسام. يسرد القسم الأول تطبيقات العميل مثل Azure VMs وAKS وApp Service. القسم التالي يسمى منطقة التوفر 1. يحتوي على قسمين منفصلين للخادم الأساسي وخادم الاستعداد. يقسم الخط المنقط قسم كل خادم إلى قسمين فرعيين، الحوسبة والتخزين. تشير الأسهم من تطبيقات العميل إلى موازن تحميل قياسي. يشير سهم واحد من موازن التحميل إلى جهاز ظاهري على الخادم الأساسي في منطقة التوفر 1. تقوم الأسهم ثنائية الاتجاه بتوصيل الجهاز الظاهري ومشاركة الملفات المتميزة ومحرك الأقراص ذي الحالة الصلبة (SSD). نقاط سهم أخرى من مشاركة الملفات المتميزة إلى تخزين كائن ثنائي كبير الحجم للنسخ الاحتياطي. سهم يسمى نقاط النسخ المتماثل غير المتزامنة المستندة إلى التخزين من الخادم الأساسي إلى خادم الاستعداد. القسم الثالث، المسمى منطقة التوفر 2، فارغ.

  استخدم قابلية الوصول العالية المحلية المكررة فقط في السيناريوهات التالية:

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

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

  توجد الخوادم في نفس المنطقة، ما يمكن أن يقلل من زمن انتقال الكتابة للتطبيقات التي تقوم بنشرها داخل تلك المنطقة.

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

متطلبات

• دعم المنطقة: يدعم قاعدة بيانات Azure لـ MySQL تكوينات منطقة التوفر المختلفة اعتمادا على منطقتك Azure. للحصول على قائمة كاملة بالمناطق، بما في ذلك أنواع دعم منطقة التوفر والاعتبارات المحددة لكل منطقة، راجع Azure المناطق.

• مستوى الخدمة: تتطلب قابلية الوصول العالية مستويات الأغراض العامة أو الذاكرة المحسنة. لا تدعم الطبقة القابلة للاندفاع قابلية الوصول العالية (المنطقة المكررة أو المكررة محليا).

Cost

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

الاعتبارات

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

• القيود والمشاكل المعروفة: راجع قائمة القيود والمشاكل المعروفة.

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

لتكوين دعم منطقة التوفر لخادم، قم بتكوين إعدادات قابلية الوصول العالية.

ملحوظة

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

• إنشاء خادم المنطقة المكررة. لمعرفة كيفية إنشاء خادم مع تمكين قابلية الوصول العالية وتكرار المنطقة، راجع المقالات التالية:

  • مدخل Azure: إدارة قابلية الوصول العالية المكررة في المنطقة في قاعدة بيانات Azure لـ MySQL باستخدام مدخل Azure.

  • Azure CLI: إدارة قابلية الوصول العالية المكررة في المنطقة في قاعدة بيانات Azure لـ MySQL باستخدام Azure CLI.

• إنشاء خادم محلي مكرر. لإنشاء خادم مع قابلية وصول عالية مكررة محليا في منطقة توفر واحدة، يجب استخدام Azure CLI أو أسلوب نشر برمجي آخر. للحصول على إرشادات Azure CLI، راجع تمكين قابلية الوصول العالية أثناء إنشاء الخادم.

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

  • لتغيير خادم موجود إلى HA متكرر في المنطقة، تحتاج إلى الترحيل إلى خادم جديد. لمزيد من المعلومات، راجع الترحيل من خادم موجود إلى خادم متكرر في المنطقة.

  • لتغيير خادم موجود إلى قابلية وصول عالية محلية زائدة عن الحاجة:

    1. تعطيل قابلية الوصول العالية، إذا تم تمكينها.

    2. تمكين قابلية الوصول العالية المحلية المكررة. يجب استخدام Azure CLI أو أسلوب نشر برمجي آخر. للحصول على إرشادات Azure CLI، راجع إدارة قابلية الوصول العالية المكررة في المنطقة في قاعدة بيانات Azure لـ MySQL باستخدام Azure CLI.

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

السلوك عندما تكون جميع المناطق صحية

يصف هذا القسم ما يجب توقعه عند تكوين الخوادم مع HA ودعم منطقة التوفر، وجميع مناطق التوفر تعمل.

• عملية عبر المناطق: تتصل تطبيقات عميل MySQL بالخادم الأساسي باستخدام اسم المجال المؤهل بالكامل لخادم قاعدة البيانات (FQDN). تجنب استخدام عنوان IP للخادم الأساسي لأنه يمكن تغيير عنوان IP، بما في ذلك أثناء عمليات تجاوز الفشل.

  يستخدم قاعدة بيانات Azure لـ MySQL تكوين نشط-سلبي حيث يتعامل الخادم الأساسي مع جميع اتصالات قاعدة البيانات والاستعلامات في منطقة التوفر الأساسية. لا يخدم خادم النسخة المتماثلة الاحتياطية نسبة استخدام الشبكة للعميل أثناء العمليات العادية.

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

  تختلف تأثيرات النسخ المتماثل اعتمادا على تكوين منطقة التوفر التي يستخدمها الخادم الخاص بك:

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

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

  • مكرر محليا: لا يتم نسخ أي حركة مرور بين المناطق.

  ملحوظة

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

السلوك أثناء فشل المنطقة

يصف هذا القسم ما يجب توقعه عند تكوين الخوادم مع HA ودعم منطقة التوفر، وهناك انقطاع في منطقة التوفر.

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

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

  • المنطقة المكررة: يكشف قاعدة بيانات Azure لـ MySQL تلقائيا عن حالات فشل منطقة التوفر عن طريق مراقبة نقاط نهاية خادم متعددة باستمرار. لمزيد من المعلومات، راجع كيفية عمل الكشف التلقائي عن تجاوز الفشل في الخوادم التي تدعم قابلية الوصول العالية.

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

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

• اخطار: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام حالة خدمة Azure لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.

  قاعدة بيانات Azure لـ MySQL بإنشاء حدث Azure Resource Health عند حدوث تجاوز فشل غير مخطط له.

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

• فقدان البيانات المتوقع: يعتمد مقدار فقدان البيانات على تكوين منطقة التوفر الخاصة بالخادم.

  • المنطقة المكررة: من المتوقع عدم فقدان البيانات أثناء تجاوز فشل المنطقة بسبب النسخ المتماثل المتزامن بين الخوادم الأساسية والخوادم الاحتياطية في مناطق مختلفة.

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

• وقت التعطل المتوقع: يعتمد مقدار وقت التعطل على تكوين منطقة التوفر الذي يستخدمه الخادم الخاص بك.

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

  • مكرر محليا: لا تتوفر الخوادم في منطقة متأثرة حتى استرداد منطقة التوفر.

• إعادة التوزيع: يعتمد سلوك إعادة توجيه نسبة استخدام الشبكة على تكوين منطقة التوفر التي يستخدمها الخادم.

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

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

استعادة المنطقة

يعتمد سلوك استرداد المنطقة على تكوين منطقة التوفر الذي يستخدمه الخادم الخاص بك.

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

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

اختبار فشل المنطقة

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

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

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

  • Azure المدخل: إيقاف مثيل خادم مرن قاعدة بيانات Azure لـ MySQL وبدء تشغيله.

  • Azure CLI: إعادة تشغيل مثيل خادم مرن قاعدة بيانات Azure لـ MySQL وإيقافه وبدء تشغيله.

القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة

يدعم قاعدة بيانات Azure لـ MySQL النسخ المتماثلة للقراءة عبر المناطق، والتي يمكنك استخدامها للحفاظ على نسخة متزامنة من قاعدة البيانات الخاصة بك في منطقة مختلفة لاسترداد أسرع.

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

النسخ المتماثلة للقراءة عبر المناطق

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

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

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

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

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

ملحوظة

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

متطلبات

• دعم المنطقة: يمكنك إنشاء نسخ متماثلة للقراءة عبر المناطق في أي منطقة تدعم قاعدة بيانات Azure لـ MySQL. لا تقتصر على Azure المناطق المقترنة.

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

الاعتبارات

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

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

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

Cost

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

تكوين دعم متعدد المناطق

• إنشاء نسخة متماثلة للقراءة: لمعرفة كيفية إنشاء نسخة متماثلة للقراءة، راجع المقالات التالية:

  • مدخل Azure: كيفية إنشاء وإدارة النسخ المتماثلة للقراءة في خادم مرن قاعدة بيانات Azure لـ MySQL باستخدام مدخل Azure

  • Azure CLI: كيفية إنشاء وإدارة النسخ المتماثلة للقراءة في خادم مرن قاعدة بيانات Azure لـ MySQL باستخدام Azure CLI

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

• إيقاف النسخ المتماثل: لمعرفة كيفية إيقاف النسخ المتماثل، راجع إيقاف النسخ المتماثل إلى خادم النسخ المتماثل.

• حذف نسخة متماثلة للقراءة: لمعرفة كيفية حذف نسخة متماثلة للقراءة، راجع حذف خادم نسخة متماثلة.

السلوك عندما تكون جميع المناطق صحية

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

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

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

السلوك أثناء فشل المنطقة

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

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

  مهم

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

  يتطلب تجاوز الفشل اتخاذ الخطوات التالية:

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

  2. أعد تكوين التطبيق الخاص بك لاستخدام الخادم الأساسي الجديد.

  لمزيد من المعلومات، راجع تجاوز الفشل.

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

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

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

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

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

• إعادة توجيه حركة المرور: أنت مسؤول عن إعادة تكوين تطبيقاتك للاتصال بالخادم الأساسي الجديد.

  ملحوظة

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

انتعاش المنطقة

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

• خذ التطبيق الخاص بك دون اتصال وانتظر النسخ المتماثل للحاق بجميع التغييرات. يتطلب هذا الأسلوب وقت تعطل التطبيق الذي هو تقريبا نفس تأخر النسخ المتماثل.

• قم بإجراء تجاوز الفشل واقبل فقدان البيانات غير المبسطة.

تذكر أنك مسؤول أيضا عن إعادة تكوين تطبيقاتك للاتصال بالخادم الأساسي الجديد كما هو مطلوب.

اختبار حالات فشل المنطقة

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

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

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

النسخ الاحتياطي والاستعادة

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

• تخزين النسخ الاحتياطي: إذا قمت بتكوين الخادم باستخدام قابلية الوصول العالية المكررة في المنطقة، يخزن النظام النسخ الاحتياطية في ZRS. بالنسبة للخوادم التي تم تكوينها دون قابلية وصول عالية أو مع قابلية وصول عالية محلية زائدة عن الحاجة، يخزن النظام النسخ الاحتياطية في LRS.

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

  فترة الاحتفاظ بالنسخ الاحتياطي الافتراضية هي 7 أيام، ولكن يمكنك تمديد الاستبقاء حتى 35 يوما. جميع النسخ الاحتياطية مشفرة.

• استعادة: تتيح لك الاستعادة في نقطة زمنية (PITR) استعادة قاعدة البيانات الخاصة بك إلى أي لحظة خلال فترة الاحتفاظ بالنسخ الاحتياطي. تنشئ عملية الاستعادة خادم قاعدة بيانات جديدا باسم خادم جديد يوفره المستخدم. يمكنك استخدام الخادم الجديد as-is أو نسخ البيانات منه.

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

  استخدم هذه الإمكانية للاسترداد من تعديلات البيانات العرضية أو أخطاء التطبيق أو سيناريوهات الاختبار.

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

لمزيد من المعلومات، راجع النسخ الاحتياطي والاستعادة في قاعدة بيانات Azure لـ MySQL.

المرونة في صيانة الخدمة

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

للتأكد من أن الخادم الخاص بك يظل متوفرا أثناء نوافذ الصيانة، اتبع هذه التوصيات:

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

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

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

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

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

اتفاقية مستوى الخدمة

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

يوفر قاعدة بيانات Azure لـ MySQL اتفاقيات مستوى الخدمة لقابلية الوصول المختلفة استنادا إلى تكوين الخادم:

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

المحتوى ذو الصلة

• موثوقية Azure
• أفضل ممارسات البنية قاعدة بيانات Azure لـ MySQL
• نظرة عامة على استمرارية الأعمال مع قاعدة بيانات Azure لـ MySQL