تعرف على مفاهيم استمرارية الأعمال باستخدام بيانات Azure لـ MySQL - خادم مرن
ينطبق على: 
قاعدة بيانات Azure ل MySQL - خادم مرن
تمكن قاعدة بيانات Azure لخادم MySQL المرن استمرارية الأعمال التي تحمي قواعد البيانات الخاصة بك في حالة حدوث انقطاع مخطط وغير مخطط له. ميزات مثل النسخ الاحتياطية التلقائية وقابلية الوصول العالية تتناول مستويات مختلفة من الحماية من الأخطاء مع وقت استرداد مختلف وتعرض فقدان البيانات. أثناء قيامك بتصميم تطبيق للحماية من الأخطاء، يجب مراعاة هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) لكل تطبيق. هدف وقت الاسترداد هو التسامح مع وقت التعطل وهدف نقطة الاسترداد هو التسامح مع فقدان البيانات بعد تعطيل خدمة قاعدة البيانات.
يوضح الجدول التالي الميزات التي توفرها Azure Database for MySQL Flexible Server.
| الميزة | الوصف | قيود |
|---|---|---|
| النسخ الاحتياطي والاسترداد | تقوم الخدمة تلقائيا بإجراء نسخ احتياطية يومية لملفات قاعدة البيانات الخاصة بك ونسخ سجلات المعاملات احتياطيا باستمرار. يمكن الاحتفاظ بالنسخ الاحتياطية لأي فترة تتراوح بين 1 إلى 35 يوما. يمكنك استعادة خادم قاعدة البيانات إلى أي نقطة زمنية خلال فترة الاحتفاظ بالنسخ الاحتياطي. يعتمد وقت الاسترداد على حجم البيانات لاستعادة + الوقت لإجراء استرداد السجل. راجع المفاهيم - النسخ الاحتياطي والاسترداد لمزيد من التفاصيل. | بيانات النسخ الاحتياطي تظل داخل المنطقة |
| النسخ الاحتياطي المحلي المكرر | يتم تخزين النسخ الاحتياطية للخدمة تلقائيا وآمنا في تخزين محلي متكرر داخل منطقة وفي نفس منطقة التوفر. النسخ الاحتياطية المحلية المكررة تنسخ ملفات بيانات النسخ الاحتياطي للخادم ثلاث مرات داخل موقع فعلي واحد في المنطقة الأساسية. يوفر تخزين النسخ الاحتياطي المحلي المكرر على الأقل 99.999999999٪ (11 تسعة) متانة الكائنات خلال سنة معينة. راجع المفاهيم - النسخ الاحتياطي والاسترداد لمزيد من التفاصيل. | متوفر في جميع المناطق |
| النسخ الاحتياطي المتكرر في المنطقة | بدءا من منتصف ديسمبر 2024، يمكن تكوين النسخ الاحتياطية للخدمة كمنطقة زائدة عن الحاجة في وقت الإنشاء. سيؤدي تمكين التكرار في المنطقة إلى نسخ حساب التخزين الخاص بك بشكل متزامن عبر ثلاث مناطق توفر Azure في المنطقة الأساسية. كل منطقة توفر موقع فعلي منفصل مع طاقة وتبريد، وشبكات مستقلة. يوفر ZRS القدرة على الصمود لموارد التخزين التي لا تقل عن 99.99999999999٪ (12 9s) على مدى سنة معينة. سيمكن هذا التكوين الاسترداد السلس أثناء الانقطاعات المناطقية. | سيتم دعم فقط في مستوى الحوسبة Business-Critical بحلول منتصف ديسمبر 2024. متوفر فقط في المناطق التي تتوفر فيها مناطق متعددة |
| النسخ الاحتياطي المكرر جغرافيا | يمكن تكوين النسخ الاحتياطية للخدمة كنسخ احتياطية جغرافية زائدة عن الحاجة في وقت الإنشاء. يؤدي تمكين التكرار الجغرافي إلى نسخ ملفات بيانات النسخ الاحتياطي للخادم في المنطقة الأساسية المقترنة لتوفير المرونة الإقليمية. يوفر تخزين النسخ الاحتياطي المكرر جغرافيا على الأقل 99.99999999999999٪ (16 تسعة) متانة الكائنات خلال سنة معينة. راجع المفاهيم - النسخ الاحتياطي والاسترداد لمزيد من التفاصيل. | متوفر في جميع مناطق Azure المقترنة |
| توفر مرتفع متكرر في المنطقة | يمكن نشر الخدمة في وضع التوفر العالي، والذي ينشر خوادم أساسية وخوادم احتياطية في منطقتين مختلفتين من مناطق التوفر داخل المنطقة. يحمي التوفر العالي المتكرر للمنطقة من حالات الفشل على مستوى المنطقة ويساعد أيضا في تقليل وقت تعطل التطبيق أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها. البيانات يتم نسخها من الخادم الأساسي بشكل متزامن إلى النسخة المتماثلة الاحتياطية. أثناء أي حدث وقت تعطل، يتعطل خادم قاعدة البيانات تلقائيا إلى النسخة المتماثلة في وضع الاستعداد. راجع المفاهيم - قابلية الوصول العالية لمزيد من التفاصيل. | مدعوم في مستويات الأغراض العامة والحوسبة الحرجة للأعمال. لا يتوفر إلا في المناطق التي تتوفر فيها مناطق متعددة. |
| مشاركات الملفات المتميزة | يتم تخزين ملفات قاعدة البيانات في مشاركات ملفات Azure المتميزة عالية التحمل والموثوقة التي توفر تكرار البيانات مع ثلاث نسخ من النسخ المتماثلة المخزنة داخل منطقة توفر مع قدرات استرداد البيانات التلقائية. راجع مشاركات ملف Premium للحصول على مزيد من التفاصيل. | البيانات المخزنة داخل منطقة توفر |
تعمل على التخفيف من وقت التعطل المخطط له
فيما يلي بعض سيناريوهات الصيانة المخطط لها التي تتسبب في وقت تعطل:
| السيناريو | العملية |
|---|---|
| تحجيم الحساب (المستخدم) | عند إجراء عملية تحجيم حساب، يتم توفير خادم مرن جديد باستخدام تكوين الحساب محجَّم. في خادم قاعدة البيانات القديم، يُسمح بإكمال نقاط التحقق النشطة، ويتم تفريغ اتصالات العميل، ويتم إلغاء أي عمليات غير ملتزم بها، ثم يتم إيقاف التشغيل. ثم يتم إرفاق التخزين بالخادم الجديد ويتم بدء تشغيل قاعدة البيانات، والتي تقوم بإجراء الاسترداد إذا لزم الأمر قبل قبول اتصالات العميل. |
| توزيع برامج جديدة (Azure) | يتم إطلاق الميزات الجديدة أو إصلاحات الأخطاء تلقائيا كجزء من الصيانة المخطط لها للخدمة، ويمكنك جدولة وقت حدوث هذه الأنشطة. لمزيد من المعلومات، راجع المستندات، وتحقق أيضا من المدخل الخاص بك |
| ترقيات الإصدار الثانوي (Azure) | تقوم قاعدة بيانات Azure لخادم MySQL المرن تلقائيا بتصحيح خوادم قاعدة البيانات إلى الإصدار الثانوي الذي تحدده Azure. يحدث ذلك كجزء من الصيانة المخطط لها للخدمة. قد يتطلب ذلك وقت تعطل قصير من حيث الثواني، ويتم إعادة تشغيل خادم قاعدة البيانات تلقائيًا باستخدام الإصدار الثانوي الجديد. لمزيد من المعلومات، راجع المستندات، وتحقق أيضا من المدخل الخاص بك. |
عند تكوين الخادم المرن مع توفر مرتفع متكرر في المنطقة، يقوم الخادم المرن بإجراء عمليات على خادم الاستعداد أولا ثم على الخادم الأساسي دون تجاوز فشل. راجع المفاهيم - قابلية الوصول العالية لمزيد من التفاصيل.
التخفيف غير المخطط له من وقت التعطل.
يمكن أن يحدث وقت تعطل غير مخطط له نتيجة لعدة محاولات فاشلة غير متوقعة، بما في ذلك أعطال الأجهزة الأساسية، ومشكلات الشبكات، وأخطاء البرامج. إذا انخفض خادم قاعدة البيانات بشكل غير متوقع، إذا تم تكوينه بتوافر عال [HA]، يتم تنشيط النسخة المتماثلة الاحتياطية. إذا لم يكن الأمر كما هو، فسيتم توفير خادم قاعدة بيانات جديد تلقائيا. بينما لا يمكن تجنب وقت تعطل غير مخطط له، فإن الخادم المرن يخفف من وقت التعطل عن طريق إجراء عمليات الاسترداد تلقائيا في كل من خادم قاعدة البيانات وطبقات التخزين دون الحاجة إلى تدخل بشري.
وقت التعطل غير المخطط له: سيناريوهات الأعطال واسترداد الخدمة
فيما يلي بعض سيناريوهات التعطل غير المخطط لها وعملية الاسترداد:
| السيناريو | عملية الاسترداد [غير عالية التوفر] | عملية الاسترداد [عالية التوفر] |
|---|---|---|
| فشل خادم قاعدة البيانات | إذا كان خادم قاعدة البيانات معطلاً بسبب بعض الأخطاء الأساسية في الأجهزة، يتم إسقاط الاتصالات النشطة، وإجهاض أي عمليات طارئة. يحاول Azure إعادة تشغيل خادم قاعدة البيانات. إذا نجح ذلك، يتم تنفيذ استرداد قاعدة البيانات. إذا فشلت إعادة التشغيل، تتم محاولة إعادة تشغيل خادم قاعدة البيانات على عقدة فعلية أخرى. يعتمد وقت الاسترداد (RTO) على عوامل مختلفة بما في ذلك النشاط في وقت الخطأ مثل المعاملة الكبيرة ومقدار الاسترداد الذي سيتم تنفيذه أثناء عملية بدء تشغيل خادم قاعدة البيانات. RPO هو صفر حيث لا يتوقع فقدان البيانات للمعاملات الملتزم بها. يجب إنشاء التطبيقات التي تستخدم قواعد بيانات MySQL بطريقة تكتشف وتعيد محاولة الاتصالات المنقطعة والعمليات الفاشلة. عند إعادة محاولة التطبيق، يتم توجيه الاتصالات إلى خادم قاعدة البيانات الذي تم إنشاؤه حديثا. الخيارات الأخرى المتوفرة هي الاستعادة من النسخ الاحتياطي. يمكنك استخدام كل من استرداد في نقطة زمنية أو استعادة الموقع الجغرافي من المنطقة المقترنة. PITR : RTO: يختلف، RPO=0sec استرداد الموقع الجغرافي: هدف وقت الاسترداد: يختلف هدف نقطة الاسترداد <1 ساعة. يمكنك أيضا استخدام النسخة المتماثلة للقراءة كحل الإصلاح بعد كارثة. يمكنك إيقاف النسخ المتماثل، ما يجعل قراءة النسخة المتماثلة للقراءة والكتابة (مستقلة ثم إعادة توجيه حركة مرور التطبيق إلى قاعدة البيانات هذه). RTO في معظم الحالات هو بضع دقائق وRPO < 1 ساعة. يمكن أن يكون RTO وRPO أعلى بكثير في بعض الحالات اعتمادا على عوامل مختلفة بما في ذلك زمن الانتقال بين المواقع، وكمية البيانات التي سيتم إرسالها، والأهم من ذلك حمل عمل كتابة قاعدة البيانات الأساسية. |
إذا تم الكشف عن فشل خادم قاعدة البيانات أو أخطاء غير قابلة للاسترداد، يتم تنشيط خادم قاعدة البيانات الاحتياطية، وبالتالي تقليل وقت التعطل. راجع صفحة مفاهيم قابلية الوصول العالية لمزيد من التفاصيل. من المتوقع أن يكون هدف وقت الاسترداد 60-120 ثانية، مع هدف نقطة الاسترداد=0. ملاحظة: خيارات عملية الاسترداد [غير HA] قابلة للتطبيق هنا أيضا. |
| فشل التخزين | لا ترى التطبيقات أي تأثير لأي مشكلات متعلقة بالتخزين مثل فشل القرص أو تلف الكتلة الفعلية. نظراً لتخزين البيانات في 3 نسخ، يتم تقديم نسخة البيانات من خلال التخزين المتبقي. يتم تصحيح تلف الكتلة تلقائيا. في حالة فقدان نسخة من البيانات، يتم إنشاء نسخة جديدة من البيانات تلقائيا. في سيناريو نادر أو أسوأ حالة إذا كانت جميع النسخ تالفة، يمكننا استخدام الاستعادة من الاستعادة الجغرافية (المنطقة المقترنة). سيكون <هدف نقطة الاسترداد 1 ساعة ويختلف هدف وقت الاسترداد. يمكنك أيضا استخدام النسخة المتماثلة للقراءة كحل الإصلاح بعد كارثة كما هو مفصل أعلاه. |
بالنسبة لهذا السيناريو، تكون الخيارات مماثلة لعملية الاسترداد [غير عالية التوفر] . |
| أخطاء منطقية/أخطاء المستخدم | يتضمن الاسترداد من أخطاء المستخدم، مثل الجداول التي تم إسقاطها عن طريق الخطأ أو البيانات المحدثة بشكل غير صحيح، إجراء استرداد في نقطة زمنية (PITR)، عن طريق استعادة البيانات واستردادها حتى وقت حدوث الخطأ مباشرة. يمكنك استرداد مورد خادم مرن محذوف في غضون خمسة أيام من وقت حذف الخادم. للحصول على دليل مفصل حول كيفية استعادة خادم محذوف، [راجع الخطوات الموثقة] (../flexible-server/how-to-restore-dropped-server.md). لحماية موارد الخادم بعد النشر من الحذف العرضي أو التغييرات غير المتوقعة، يمكن للمسؤولين استخدام تأمينات الإدارة. |
أخطاء المستخدم هذه غير محمية بتوافر عال نظرا لأن جميع عمليات المستخدم يتم نسخها نسخا متماثلا إلى وضع الاستعداد أيضا. بالنسبة لهذا السيناريو، تكون الخيارات مماثلة لعملية الاسترداد [غير عالية التوفر] |
| فشل منطقة قابلية الوصول | في حين أنه حدث نادر، إذا كنت تريد الاسترداد من فشل على مستوى المنطقة، يمكنك إجراء استعادة جغرافية من إلى منطقة مقترنة. سيكون <هدف نقطة الاسترداد 1 ساعة ويختلف هدف وقت الاسترداد. يمكنك أيضا استخدام النسخة المتماثلة للقراءة كحل الإصلاح بعد كارثة عن طريق إنشاء نسخة متماثلة في منطقة توفر أخرى. هدف وقت الاسترداد\هدف نقطة الاسترداد يشبه ما هو مفصل أعلاه. |
إذا قمت بتمكين قابلية الوصول العالية المكررة للمنطقة، يقوم الخادم المرن بتجاوز الفشل التلقائي إلى موقع الاستعداد. راجع صفحة مفاهيم التوفر العالي لمزيد من التفاصيل. من المتوقع أن يكون هدف وقت الاسترداد 60-120 ثانية، مع هدف نقطة الاسترداد=0. الخيارات الأخرى المتوفرة هي الاستعادة من النسخ الاحتياطي. يمكنك استخدام كل من استرداد في نقطة زمنية أو استعادة الموقع الجغرافي من المنطقة المقترنة. PITR: RTO: يختلف، RPO=0 ثانية الاستعادة الجغرافية: RTO: يختلف، RPO <1 ساعة ملاحظة: إذا كان لديك نفس المنطقة HA ممكنة، فإن الخيارات هي نفسها لعملية الاسترداد [غير HA]. |
| فشل المنطقة | في حين أنه حدث نادر، إذا كنت تريد الاسترداد من فشل على مستوى المنطقة، يمكنك إجراء استرداد قاعدة البيانات عن طريق إنشاء خادم جديد باستخدام أحدث نسخ احتياطي مكرر جغرافيا متوفر ضمن نفس الاشتراك للوصول إلى أحدث البيانات. يتم نشر خادم مرن جديد في المنطقة المحددة. يعتمد الوقت المستغرق للاستعادة على النسخ الاحتياطي السابق وعدد سجلات المعاملات للاسترداد. سيكون <هدف نقطة الاسترداد في معظم الحالات 1 ساعة ويختلف هدف وقت الاسترداد. | بالنسبة لهذا السيناريو، تكون الخيارات مماثلة لعملية الاسترداد [غير عالية التوفر] . |
المتطلبات والقيود
موقع بيانات المنطقة
بشكل افتراضي، لا تنقل قاعدة بيانات Azure لخادم MySQL المرن بيانات العملاء أو تخزنها خارج المنطقة التي تم نشرها فيها. ومع ذلك، يمكن للعملاء اختياريا اختيار تمكين النسخ الاحتياطية المتكررة جغرافيا أو إعداد النسخ المتماثل عبر المناطق لتخزين البيانات في منطقة أخرى.
الخطوات التالية
- تعرف على قابلية الوصول العالية في المنطقة المكررة
- تعرف على معلومات حول النسخ الاحتياطي والاسترداد