نظرة عامة على استمرارية الأعمال مع قاعدة بيانات Azure ل MySQL - خادم مرن
ينطبق على:
قاعدة بيانات Azure ل MySQL - خادم مرن
تتيح قاعدة بيانات Azure ل MySQL Flexible Server إمكانات استمرارية الأعمال التي تحمي قواعد البيانات الخاصة بك في حالة حدوث انقطاع مخطط له وغير مخطط له. تعالج ميزات مثل النسخ الاحتياطي التلقائي والتوفر العالي مستويات مختلفة من الحماية من الأخطاء مع وقت استرداد مختلف والتعرض لفقدان البيانات. أثناء تصميم تطبيقك للحماية من الأخطاء، يجب مراعاة هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) لكل تطبيق. RTO هو التسامح مع وقت التوقف عن العمل و RPO هو التسامح مع فقدان البيانات بعد انقطاع خدمة قاعدة البيانات.
يوضح الجدول أدناه الميزات التي يوفرها الخادم المرن.
| الميزة | الوصف | القيود |
|---|---|---|
| استعادة النسخ الاحتياطي & | يقوم الخادم المرن تلقائيا بإجراء نسخ احتياطية يومية من ملفات قاعدة البيانات الخاصة بك ويقوم بعمل نسخة احتياطية باستمرار من سجلات المعاملات. يمكن الاحتفاظ بالنسخ الاحتياطية لأي فترة تتراوح بين 1 إلى 35 يوما. ستتمكن من استعادة خادم قاعدة البيانات إلى أي وقت خلال فترة الاحتفاظ بالنسخة الاحتياطية. يعتمد وقت الاسترداد على حجم البيانات لاستعادة + الوقت اللازم لإجراء استرداد السجل. ارجع إلى المفاهيم - النسخ الاحتياطي والاستعادة لمزيد من التفاصيل. | تبقى بيانات النسخ الاحتياطي داخل المنطقة |
| النسخ الاحتياطي المحلي الزائد | يتم تخزين النسخ الاحتياطية المرنة للخادم تلقائيا وبشكل آمن في وحدة تخزين احتياطية محلية داخل منطقة وفي نفس منطقة توافر الخدمات. النسخ الاحتياطية الزائدة محليا نسخ ملفات بيانات النسخ الاحتياطي للخادم ثلاث مرات داخل موقع فعلي واحد في المنطقة الأساسية. يوفر التخزين الاحتياطي المتكرر محليا متانة لا تقل عن 99.99999999999٪ (11 تسعة) للكائنات خلال سنة معينة. ارجع إلى المفاهيم - النسخ الاحتياطي والاستعادة لمزيد من التفاصيل. | قابل للتطبيق في جميع المناطق |
| النسخ الاحتياطي الجغرافي الزائد | يمكن تكوين النسخ الاحتياطية المرنة للخادم على أنها زائدة عن الحاجة جغرافيا في وقت الإنشاء. يؤدي تمكين التكرار الجغرافي إلى نسخ ملفات بيانات النسخ الاحتياطي للخادم في المنطقة المقترنة ™الأساسية لتوفير المرونة الإقليمية. يوفر التخزين الاحتياطي المتكرر جغرافيا متانة لا تقل عن 99.9999999999999999999٪ (16 تسعة) للكائنات خلال سنة معينة. ارجع إلى المفاهيم - النسخ الاحتياطي والاستعادة لمزيد من التفاصيل. | متوفر في جميع مناطق Azure المقترنة |
| توفر مرتفع متكرر في المنطقة | يمكن نشر الخادم المرن في وضع التوافر العالي، الذي ينشر الخوادم الأساسية والاحتياطية في منطقتي توافر خدمات مختلفتين داخل المنطقة. هذا يحمي من الفشل على مستوى المنطقة ويساعد أيضا في تقليل وقت تعطل التطبيق أثناء أحداث التوقف عن العمل المخطط لها وغير المخطط لها. يتم نسخ البيانات من الخادم الأساسي بشكل متزامن إلى النسخة المتماثلة الاحتياطية. أثناء أي حدث وقت توقف، يتم فشل خادم قاعدة البيانات تلقائيا في النسخة المتماثلة في وضع الاستعداد. ارجع إلى المفاهيم - التوافر العالي لمزيد من التفاصيل. | مدعوم في طبقات الحوسبة المحسنة للأغراض العامة والذاكرة. متوفر فقط في المناطق التي تتوفر فيها مناطق متعددة. |
| مشاركات الملفات Premium | يتم تخزين ملفات قاعدة البيانات في مشاركات ملفات Azure المميزة عالية المتانة والموثوقة التي توفر تكرار البيانات مع ثلاث نسخ من النسخ المتماثلة المخزنة داخل منطقة توافر الخدمات مع إمكانات استرداد البيانات تلقائيا. راجع Premium مشاركات الملفات للحصول على مزيد من التفاصيل. | البيانات المخزنة داخل منطقة توافر الخدمات |
التخفيف من وقت التوقف المخطط له
فيما يلي بعض سيناريوهات الصيانة المخطط لها التي تؤدي إلى توقف عن العمل:
| السيناريو | عملية |
|---|---|
| قياس الحوسبة (مستخدم) | عند تنفيذ عملية قياس الحوسبة، يتم توفير خادم مرن جديد باستخدام تكوين الحوسبة المقاسة. في خادم قاعدة البيانات الموجود، يسمح لنقاط التفتيش النشطة بالاكتمال، ويتم استنزاف اتصالات العميل، ويتم إلغاء أي معاملات غير ملتزم بها، ثم يتم إيقاف تشغيلها. ثم يتم إرفاق التخزين بالخادم الجديد ويتم بدء تشغيل قاعدة البيانات التي تقوم بالاسترداد إذا لزم الأمر قبل قبول اتصالات العميل. |
| نشر البرامج الجديدة (Azure) | يحدث طرح الميزات الجديدة أو إصلاحات الأخطاء تلقائيا كجزء من الصيانة المخطط لها للخدمة، ويمكنك جدولة وقت حدوث هذه الأنشطة. لمزيد من المعلومات، راجع الوثائق، وتحقق أيضا من البوابة الإلكترونية |
| ترقيات الإصدارات الثانوية (Azure) | تقوم قاعدة بيانات Azure ل MySQL تلقائيا بتصحيح خوادم قاعدة البيانات إلى الإصدار الثانوي الذي يحدده Azure. يحدث ذلك كجزء من الصيانة المخطط لها للخدمة. سيؤدي ذلك إلى توقف قصير من حيث الثواني ، ويتم إعادة تشغيل خادم قاعدة البيانات تلقائيا باستخدام الإصدار الثانوي الجديد. لمزيد من المعلومات، راجع الوثائق، وتحقق أيضا من البوابة الإلكترونية. |
عندما يتم تكوين الخادم المرن مع توفر عالي زائد عن الحاجة في المنطقة، يقوم الخادم المرن بتنفيذ العمليات على خادم الاستعداد أولا ثم على الخادم الأساسي دون تجاوز الفشل. ارجع إلى المفاهيم - التوافر العالي لمزيد من التفاصيل.
تخفيف وقت التوقف عن العمل غير المخطط له
يمكن أن تحدث أوقات التوقف غير المخطط لها نتيجة لحالات فشل غير متوقعة، بما في ذلك خطأ الأجهزة الأساسي ومشكلات الشبكات وأخطاء البرامج. إذا تعطل خادم قاعدة البيانات بشكل غير متوقع، إذا تم تكوينه مع توفر عال [HA]، تنشيط النسخة المتماثلة في وضع الاستعداد. إذا لم يكن الأمر كذلك ، توفير خادم قاعدة بيانات جديد تلقائيا. على الرغم من أنه لا يمكن تجنب وقت التوقف عن العمل غير المخطط له ، إلا أن الخادم المرن يخفف من وقت التوقف عن العمل من خلال إجراء عمليات الاسترداد تلقائيا في كل من خادم قاعدة البيانات وطبقات التخزين دون الحاجة إلى تدخل بشري.
وقت التوقف غير المخطط له: سيناريوهات الفشل واسترداد الخدمة
فيما يلي بعض سيناريوهات الفشل غير المخطط لها وعملية الاسترداد:
| السيناريو | عملية الاسترداد [غير HA] | عملية الاسترداد [HA] |
|---|---|---|
| فشل في خادم قاعدة البيانات | إذا كان خادم قاعدة البيانات معطلا بسبب بعض أخطاء الأجهزة الأساسية، يتم إسقاط الاتصالات النشطة، ويتم إحباط أي معاملات على متن الطائرة. سيحاول Azure إعادة تشغيل خادم قاعدة البيانات. إذا نجح ذلك ، تنفيذ استرداد قاعدة البيانات. في حالة فشل إعادة التشغيل، ستتم محاولة إعادة تشغيل خادم قاعدة البيانات على عقدة فعلية أخرى. يعتمد وقت الاسترداد (RTO) على عوامل مختلفة بما في ذلك النشاط في وقت الخطأ مثل المعاملة الكبيرة ومقدار الاسترداد الذي يتعين القيام به أثناء عملية بدء تشغيل خادم قاعدة البيانات. سيكون RPO صفرا حيث لا يتوقع فقدان البيانات للمعاملات الملتزم بها. يجب إنشاء التطبيقات التي تستخدم قواعد بيانات MySQL بطريقة تكتشف وتعيد محاولة الاتصالات المتساقطة والمعاملات الفاشلة. عند إعادة تشغيل التطبيق، يتم توجيه الاتصالات إلى خادم قاعدة البيانات الذي تم إنشاؤه حديثا. الخيارات الأخرى المتاحة هي الاستعادة من النسخة الاحتياطية. يمكنك استخدام كل من PITR أو Geo restore من المنطقة المقترنة. PITR : RTO : يختلف ، RPO = 0sec استعادة الجغرافية: RTO: يختلف RPO <15 دقيقة. يمكنك أيضا استخدام النسخة المتماثلة المقروءة كحل DR. يمكنك إيقاف النسخ المتماثل الذي يجعل قراءة النسخة المتماثلة قراءة وكتابة (مستقلة ثم إعادة توجيه حركة مرور التطبيق إلى قاعدة البيانات هذه. سيكون RTO في معظم الحالات بضع دقائق و RPO < 5 دقائق. يمكن أن يكون RTO و RPO أعلى بكثير في بعض الحالات اعتمادا على عوامل مختلفة بما في ذلك الكمون بين المواقع ، وكمية البيانات التي سيتم نقلها ، والأهم من ذلك عبء عمل كتابة قاعدة البيانات الأولية. |
إذا تم الكشف عن فشل خادم قاعدة البيانات أو أخطاء غير قابلة للاسترداد، يتم تنشيط خادم قاعدة البيانات الاستعداد، وبالتالي تقليل وقت التوقف. ارجع إلى صفحة مفاهيم HA لمزيد من التفاصيل. من المتوقع أن يكون RTO 60-120 ثانية ، مع RPO = 0. ملاحظة:خيارات عملية الاسترداد [غير HA] قابلة للتطبيق أيضا هنا. قراءة النسخة المتماثلة غير مدعومة حاليا للخوادم التي تدعم HA. |
| فشل في التخزين | لا ترى التطبيقات أي تأثير لأي مشكلات متعلقة بالتخزين مثل فشل القرص أو تلف الكتلة الفعلية. نظرا لأن البيانات مخزنة في ثلاث نسخ ، يتم تقديم نسخة البيانات بواسطة التخزين الباقي. يتم تصحيح تلف الحظر تلقائيا. في حالة فقدان نسخة من البيانات، يتم إنشاء نسخة جديدة من البيانات تلقائيا. في سيناريو نادر أو أسوأ الحالات في حالة تلف جميع النسخ، يمكننا استخدام الاستعادة من Geo restore (المنطقة المقترنة). سيكون <RPO 15 دقيقة وسيختلف RTO. يمكنك أيضا استخدام قراءة النسخة المتماثلة كحل DR كما هو مفصل أعلاه. |
بالنسبة لهذا السيناريو، تكون الخيارات هي نفسها كما هو الحال بالنسبة لعملية الاسترداد [غير HA] . قراءة النسخة المتماثلة غير مدعومة حاليا للخوادم التي تدعم HA. |
| الأخطاء المنطقية/أخطاء المستخدم | يتضمن الاسترداد من أخطاء المستخدم، مثل الجداول التي تم إسقاطها عن طريق الخطأ أو البيانات المحدثة بشكل غير صحيح، إجراء استرداد في الوقت المناسب (PITR)، عن طريق استعادة البيانات واستردادها حتى الوقت السابق لحدوث الخطأ مباشرة. يمكنك استرداد مورد خادم MySQL مرن محذوف في غضون خمسة أيام من وقت حذف الخادم. للحصول على دليل مفصل حول كيفية استعادة خادم محذوف، [راجع الخطوات الموثقة] (.. /مرن-خادم/كيفية-استعادة-إسقاط-server.md). لحماية موارد الخادم بعد النشر من الحذف العرضي أو التغييرات غير المتوقعة، يمكن للمسؤولين الاستفادة من أقفال الإدارة. |
لا تتم حماية أخطاء المستخدم هذه مع توفر عال نظرا لأن جميع عمليات المستخدم يتم نسخها إلى وضع الاستعداد أيضا. بالنسبة لهذا السيناريو، تكون الخيارات هي نفسها بالنسبة لعملية الاسترداد [non-HA] |
| فشل منطقة توافر الخدمات | على الرغم من أنه حدث نادر الحدوث، إذا كنت ترغب في التعافي من فشل على مستوى المنطقة، فيمكنك إجراء استعادة Geo من منطقة مقترنة. سيكون <RPO 15 دقيقة وسيختلف RTO. يمكنك أيضا استخدام النسخة المتماثلة المقروءة كحل DR عن طريق إنشاء نسخة متماثلة في منطقة توافر الخدمات الأخرى. RTO \ RPO يشبه ما هو مفصل أعلاه. |
إذا قمت بتمكين المنطقة الزائدة عن الحاجة، يقوم الخادم المرن بتنفيذ تجاوز الفشل التلقائي إلى موقع الاستعداد. ارجع إلى مفاهيم HA لمزيد من التفاصيل. من المتوقع أن يكون RTO 60-120 ثانية ، مع RPO = 0. تتم استعادة الخيارات الأخرى المتاحة من النسخة الاحتياطية. يمكنك استخدام كل من PITR أو Geo restore من المنطقة المقترنة. بيتر : RTO: يختلف، RPO = 0 ثانية استعادة الجغرافية: RTO: يختلف، RPO <15 دقيقة ملاحظة:إذا كان لديك نفس المنطقة HA تمكين الخيارات هي نفسها ما لدينا لعملية الاسترداد [غير HA] |
| فشل في المنطقة | على الرغم من أنه حدث نادر الحدوث، إذا كنت ترغب في التعافي من فشل على مستوى المنطقة، فيمكنك إجراء استرداد قاعدة البيانات عن طريق إنشاء خادم جديد باستخدام أحدث نسخة احتياطية جغرافية متوفرة تحت نفس الاشتراك للوصول إلى أحدث البيانات. سيتم نشر خادم مرن جديد في المنطقة المحددة. يعتمد الوقت المستغرق للاستعادة على النسخة الاحتياطية السابقة وعدد سجلات المعاملات المراد استردادها. سيكون <RPO في معظم الحالات 15 دقيقة وسيختلف RTO. | بالنسبة لهذا السيناريو، تكون الخيارات هي نفسها كما هو الحال بالنسبة لعملية الاسترداد [غير HA] . |
الخطوات التالية
- تعرف على التوافر العالي للمنطقة الزائدة عن الحاجة
- تعرف على النسخ الاحتياطي والاسترداد