مفاهيم التوفر العالي في قاعدة بيانات Azure لخادم MySQL المرن
ينطبق على:
قاعدة بيانات Azure ل MySQL - خادم مرن
تسمح قاعدة بيانات Azure لخادم MySQL المرن بقابلية توافر عالية مع إمكانية تجاوز الفشل التلقائي. تم تصميم حل التوافر العالي لضمان عدم فقدان البيانات الملتزمة أبدا بسبب الفشل وأن قاعدة البيانات لن تكون نقطة فشل واحدة في بنية البرنامج الخاص بك. عند تكوين التوفر العالي، يوفر الخادم المرن تلقائيًا نسخة متماثلة في وضع الاستعداد ويديرها. تتم محاسبتك على الحوسبة والتخزين الموفرين لكل من النسخة المتماثلة الأساسية والثانوية. هناك نوعان من النماذج المعمارية عالية التوافر:
HA زائدة عن الحاجة في المنطقة. يفضل هذا الخيار للعزل الكامل للبنية التحتية وتكرارها عبر مناطق توافر الخدمات المتعددة. يوفر أعلى مستوى من التوافر ، ولكنه يتطلب منك تكوين تكرار التطبيق عبر المناطق. يفضل HA الزائدة عن الحاجة في المنطقة عندما تريد تحقيق أعلى مستوى من التوافر مقابل أي فشل في البنية التحتية في منطقة توافر الخدمات وعندما يكون زمن الوصول عبر منطقة توافر الخدمات مقبولا. يمكن تمكينه فقط عند إنشاء الخادم. يتوفر HA المكرر للمنطقة في مجموعة فرعية من مناطق Azure حيث تدعم المنطقة مناطق توافر خدمات متعددة وتتوفر مشاركات ملفات Premium الزائدة عن الحاجة للمنطقة.
نفس المنطقة HA. يفضل هذا الخيار لتكرار البنية التحتية مع زمن انتقال أقل للشبكة لأن الخوادم الأساسية والاحتياطية ستكون في نفس منطقة توافر الخدمات. يوفر توافرا عاليا دون الحاجة إلى تكوين تكرار التطبيق عبر المناطق. يفضل HA في نفس المنطقة عندما تريد تحقيق أعلى مستوى من التوافر داخل منطقة توافر خدمات واحدة بأقل زمن انتقال للشبكة. يتوفر HA في نفس المنطقة في جميع مناطق Azure حيث يمكنك استخدام قاعدة بيانات Azure ل MySQL - الخادم المرن.
بنية HA الزائدة عن الحاجة للمنطقة
عند نشر خادم يحتوي على HA زائدة عن الحاجة للمنطقة، سيتم إنشاء خادمين:
- خادم أساسي في منطقة توافر خدمات واحدة
- خادم نسخة متماثلة في وضع الاستعداد له نفس تكوين الخادم الأساسي (طبقة الحوسبة وحجم الحوسبة وحجم التخزين وتكوين الشبكة) في منطقة توافر خدمات أخرى من منطقة Azure نفسها
يمكنك اختيار منطقة توافر الخدمات للنسخة المتماثلة الأساسية والاحتياطية. يؤدي وضع خوادم قاعدة البيانات الاحتياطية وتطبيقات الاستعداد في نفس المنطقة إلى تقليل زمن الاستجابة. كما يسمح لك بالاستعداد بشكل أفضل لحالات التعافي من الكوارث وسيناريوهات "المنطقة السفلية".
تتم استضافة البيانات وملفات السجل في وحدة تخزين زائدة عن الحاجة (ZRS). يتم نسخ هذه الملفات إلى خادم الاستعداد عبر النسخ المتماثل على مستوى التخزين المتوفر مع ZRS. إذا كان هناك تجاوز للفشل:
- يتم تنشيط النسخة المتماثلة الاحتياطية.
- تستمر ملفات السجل الثنائي للخادم الأساسي في التطبيق على خادم الاستعداد لإحضاره عبر الإنترنت إلى آخر معاملة تم الالتزام بها على الخادم الأساسي.
يمكن الوصول إلى سجلات ZRS حتى عندما يكون الخادم الأساسي غير متوفر. يساعد هذا التوافر على ضمان عدم فقدان البيانات. بعد تنشيط النسخة المتماثلة في وضع الاستعداد وتطبيق السجلات الثنائية، يأخذ خادم النسخ المتماثلة في وضع الاستعداد الحالي دور الخادم الأساسي. يتم تحديث DNS بحيث يتم توجيه اتصالات العميل إلى الأساسي الجديد عند إعادة اتصال العميل. تجاوز الفشل شفاف تماما من تطبيق العميل ولا يتطلب أي إجراء منك. ثم يعيد حل HA الخادم الأساسي القديم عندما يكون ذلك ممكنا ويضعه كوضع احتياطي.
يتم استخدام اسم خادم قاعدة البيانات لتوصيل التطبيقات بالخادم الأساسي. لا يتم الكشف عن معلومات النسخ المتماثلة في وضع الاستعداد للوصول المباشر. يتم الاعتراف بالالتزامات والكتابات بعد مسح ملفات السجل في ZRS الخاص بالخادم الأساسي. بسبب تقنية النسخ المتماثل للمزامنة المستخدمة في تخزين ZRS ، يمكنك توقع زيادة زمن الوصول بنسبة 5-10 بالمائة لعمليات كتابة التطبيقات والتزامها.
يتم تنفيذ النسخ الاحتياطي التلقائي، سواء اللقطات أو النسخ الاحتياطية للسجل، على وحدة تخزين زائدة عن الحاجة من خادم قاعدة البيانات الأساسي.
بنية HA في نفس المنطقة
عند نشر خادم بنفس المنطقة HA، سيتم إنشاء خادمين في نفس المنطقة:
- خادم أساسي
- خادم نسخة متماثلة في وضع الاستعداد له نفس تكوين الخادم الأساسي (طبقة الحوسبة وحجم الحساب وحجم التخزين وتكوين الشبكة)
يوفر خادم الاستعداد تكرار البنية التحتية مع جهاز ظاهري منفصل (حوسبة). يقلل هذا التكرار من وقت تجاوز الفشل وزمن انتقال الشبكة بين التطبيق وخادم قاعدة البيانات بسبب الموقع المشترك.
تتم استضافة البيانات وملفات السجل في وحدة تخزين زائدة عن الحاجة محليا (LRS). يتم نسخ هذه الملفات إلى خادم الاستعداد عبر النسخ المتماثل على مستوى التخزين المتوفر مع LRS.
إذا كان هناك تجاوز للفشل:
- يتم تنشيط النسخة المتماثلة الاحتياطية.
- تستمر ملفات السجل الثنائي للخادم الأساسي في التطبيق على خادم الاستعداد لإحضاره عبر الإنترنت إلى آخر معاملة تم الالتزام بها على الخادم الأساسي.
يمكن الوصول إلى سجلات LRS حتى عندما يكون الخادم الأساسي غير متوفر. يساعد هذا التوافر على ضمان عدم فقدان البيانات. بعد تنشيط النسخة المتماثلة في وضع الاستعداد وتطبيق السجلات الثنائية، تأخذ النسخة المتماثلة الحالية في وضع الاستعداد دور الخادم الأساسي. يتم تحديث DNS لإعادة توجيه الاتصالات إلى الأساسي الجديد عند إعادة اتصال العميل. تجاوز الفشل شفاف تماما من تطبيق العميل ولا يتطلب أي إجراء منك. ثم يعيد حل HA الخادم الأساسي القديم عندما يكون ذلك ممكنا ويضعه كوضع احتياطي.
يتم استخدام اسم خادم قاعدة البيانات لتوصيل التطبيقات بالخادم الأساسي. لا يتم الكشف عن معلومات النسخ المتماثلة في وضع الاستعداد للوصول المباشر. يتم الاعتراف بالالتزامات والكتابات بعد مسح ملفات السجل في LRS الخاص بالخادم الأساسي. نظرا لأن النسخة المتماثلة الأساسية والاحتياطية في نفس المنطقة، فهناك تأخر أقل في النسخ المتماثل وزمن انتقال أقل بين خادم التطبيقات وخادم قاعدة البيانات. لا يوفر إعداد المنطقة نفسها توافرا عاليا عندما تكون البنى التحتية التابعة معطلة لمنطقة توافر الخدمات المحددة. سيكون هناك وقت توقف حتى تعود جميع الخدمات التابعة إلى الإنترنت لمنطقة توافر الخدمات هذه.
يتم تنفيذ النسخ الاحتياطي التلقائي، سواء اللقطات أو النسخ الاحتياطية للسجل، على وحدة تخزين زائدة عن الحاجة محليا من خادم قاعدة البيانات الأساسي.
ملاحظة
لكل من المنطقة الزائدة عن الحاجة والمنطقة نفسها HA:
- إذا كان هناك فشل، فإن الوقت اللازم لنسخة احتياطية لتولي دور الأساسي يعتمد على تطبيق السجل الثنائي في وضع الاستعداد. لذلك نوصي باستخدام المفاتيح الأساسية على جميع الجداول لتقليل وقت تجاوز الفشل. تتراوح أوقات تجاوز الفشل عادة بين 60 و 120 ثانية.
- خادم الاستعداد غير متوفر لعمليات القراءة أو الكتابة. إنه وضع الاستعداد السلبي لتمكين تجاوز الفشل السريع.
- استخدم دائما اسم نطاق مؤهل بالكامل (FQDN) للاتصال بالخادم الأساسي. تجنب استخدام عنوان IP للاتصال. إذا كان هناك تجاوز فشل، بعد تبديل أدوار الخادم الأساسي والاحتياطي، فقد يتغير سجل DNS A. سيمنع هذا التغيير التطبيق من الاتصال بالخادم الأساسي الجديد إذا تم استخدام عنوان IP في سلسلة الاتصال.
عملية تجاوز الفشل
المخطط له: تجاوز الفشل القسري
قاعدة بيانات Azure ل MySQL - يتيح لك تجاوز الفشل القسري للخادم المرن فرض تجاوز الفشل يدويا. تتيح لك هذه الإمكانية اختبار الوظائف باستخدام سيناريوهات التطبيق وتساعد على جعلك مستعدا لانقطاع التيار الكهربائي.
يؤدي تجاوز الفشل القسري إلى تشغيل تجاوز فشل يقوم بتنشيط النسخة المتماثلة في وضع الاستعداد لتصبح الخادم الأساسي بنفس اسم خادم قاعدة البيانات عن طريق تحديث سجل DNS. تتم إعادة تشغيل الخادم الأساسي الأصلي وتحويله إلى النسخة المتماثلة في وضع الاستعداد. يتم قطع اتصال اتصالات العميل وتحتاج إلى إعادة الاتصال لاستئناف عملياتها.
يعتمد وقت تجاوز الفشل الإجمالي على عبء العمل الحالي ونقطة التفتيش الأخيرة. بشكل عام ، من المتوقع أن يستغرق الأمر ما بين 60 و 120 ثانية.
غير مخطط له: تجاوز الفشل التلقائي
يمكن أن يحدث وقت تعطل الخدمة غير المخطط له بسبب أخطاء البرامج أو أخطاء البنية التحتية مثل فشل الحوسبة أو الشبكة أو التخزين أو انقطاع التيار الكهربائي الذي يؤثر على توفر قاعدة البيانات. إذا أصبحت قاعدة البيانات غير متوفرة، يتم قطع النسخ المتماثل إلى النسخة المتماثلة الاحتياطية ويتم تنشيط النسخة المتماثلة في وضع الاستعداد كقاعدة البيانات الأساسية. يتم تحديث DNS، ويقوم العملاء بإعادة الاتصال بخادم قاعدة البيانات واستئناف عملياتهم.
ومن المتوقع أن يتراوح إجمالي وقت تجاوز الفشل بين 60 و 120 ثانية. ولكن استنادا إلى النشاط في خادم قاعدة البيانات الأساسي في وقت تجاوز الفشل (مثل المعاملات الكبيرة ووقت الاسترداد)، قد يستغرق تجاوز الفشل وقتا أطول.
كيفية عمل الكشف التلقائي عن تجاوز الفشل في الخوادم التي تدعم HA
يحتوي الخادم الأساسي والخادم الثانوي على نقطتي نهاية للشبكة ،
- نقطة نهاية العميل: يقوم العميل بالاتصال بالاستعلام وتشغيله على المثيل باستخدام نقطة النهاية هذه.
- نقطة نهاية الإدارة: تستخدم داخليا لاتصالات الخدمة بمكونات الإدارة وللاتصال بوحدة التخزين الخلفية.
يقوم مكون مراقبة الصحة باستمرار بإجراء الفحوصات التالية
- تقوم الشاشة بالاتصال بنقطة نهاية شبكة إدارة العقد. إذا فشل هذا الفحص مرتين متواصلتين، فإنه يؤدي إلى تشغيل عملية تجاوز الفشل التلقائية. السيناريو مثل العقدة غير متوفر / لا يستجيب بسبب مشكلة في نظام التشغيل ، وسيتم معالجة مشكلة الشبكات بين مكونات الإدارة والعقد وما إلى ذلك من خلال هذا الفحص الصحي.
- تقوم الشاشة أيضا بتشغيل استعلام بسيط على المثيل. إذا فشلت الاستعلامات في التشغيل، تشغيل تجاوز الفشل التلقائي. سيتم التعامل مع سيناريوهات مثل MySQL demon تحطمت / توقفت / علقت ، ومشكلة التخزين الخلفية وما إلى ذلك ، من خلال هذا الفحص الصحي.
ملاحظة
إذا كانت هناك أي مشكلة في الشبكة بين التطبيق ونقطة نهاية شبكة العميل (الوصول الخاص/العام)، إما في مسار الشبكة أو على نقطة النهاية أو مشكلات DNS في جانب العميل، فإن فحص الحماية لا يراقب هذا السيناريو. إذا كنت تستخدم الوصول الخاص، تأكد من أن قواعد NSG الخاصة ب VNet لا تمنع الاتصال بنقطة نهاية شبكة عملاء المثيل على المنفذ 3306. للوصول العام، تأكد من تعيين قواعد جدار الحماية والسماح بحركة مرور الشبكة على المنفذ 3306 (إذا كان مسار الشبكة يحتوي على أي جدران حماية أخرى). يجب أيضا الاهتمام بدقة DNS من جانب تطبيق العميل.
المراقبة من أجل التوافر العالي
تتم مراقبة صحة HA باستمرار والإبلاغ عنها في صفحة النظرة العامة. فيما يلي حالات النسخ المتماثل:
| الحالة | الوصف |
|---|---|
| غير ممكن | لم يتم تمكين HA الزائدة عن الحاجة في المنطقة. |
| النسخ المتماثلالبياناتالبيانات | الاستعداد هو اللحاق بالركب مع الخادم الأساسي بعد إنشائه. |
| الفشلأكثر من ذلك | خادم قاعدة البيانات في طور الفشل من الأساسي إلى الاستعداد. |
| سليم | HA الزائدة عن الحاجة في المنطقة في حالة مستقرة وصحية. |
| إزالةالاستعداد | قام مستخدم بحذف النسخة المتماثلة في وضع الاستعداد، والحذف قيد المعالجة. |
التقييدات
فيما يلي بعض الاعتبارات التي يجب مراعاتها عند استخدام التوافر العالي:
- لا يمكن تعيين التوفر العالي المتكرر للمنطقة إلا عند إنشاء الخادم المرن.
- التوفر العالي غير مدعوم في طبقة الحوسبة القابلة للانفجار.
- إعادة تشغيل خادم قاعدة البيانات الأساسي لالتقاط تغييرات المعلمات الثابتة أيضا إعادة تشغيل النسخة المتماثلة الاستعداد.
- قراءة النسخ المتماثلة غير مدعومة لخوادم HA.
- النسخ المتماثل للبيانات في غير مدعوم لخوادم HA.
- سيتم تشغيل وضع GTID حيث يستخدم حل HA GTID. تحقق مما إذا كان عبء العمل الخاص بك يحتوي على قيود أو قيود على النسخ المتماثل باستخدام GTIDs.
ملاحظة
إذا كنت تقوم بتمكين HA في نفس المنطقة بعد إنشاء الخادم ، فأنت بحاجة إلى التأكد من تعيين معلمات الخادم enforce_gtid_consistency" و " gtid_mode" إلى ON قبل تمكين HA.
الأسئلة المتداولة (FAQ)
كيف تتم محاسبتي على خوادم (HA) عالية التوافر؟ تحتوي الخوادم الممكنة باستخدام HA على نسخة طبق الأصل أساسية وثانوية. يمكن أن تكون النسخة المتماثلة الثانوية في نفس المنطقة أو المنطقة زائدة عن الحاجة. تتم محاسبتك على الحوسبة والتخزين الموفرين لكل من النسخة المتماثلة الأساسية والثانوية. على سبيل المثال، إذا كان لديك ملف أساسي يحتوي على 4 vCores للحوسبة و512 غيغابايت من مساحة التخزين المتوفرة، فستحتوي النسخة المتماثلة الثانوية أيضا على 4 vCores و512 غيغابايت من مساحة التخزين المتوفرة. ستتم فوترة خادم HA المتكرر في منطقتك مقابل 8 vCores و 1,024 GB من التخزين. بناء على حجم تخزين النسخ الاحتياطي، قد تتم محاسبتك أيضا على مساحة تخزين النسخ الاحتياطي.
هل يمكنني استخدام النسخة المتماثلة الاحتياطية لعمليات القراءة أو الكتابة؟ خادم الاستعداد غير متوفر لعمليات القراءة أو الكتابة. إنه وضع الاستعداد السلبي لتمكين تجاوز الفشل السريع.
هل سأفقد البيانات عند حدوث تجاوز الفشل؟ يمكن الوصول إلى سجلات ZRS حتى عندما يكون الخادم الأساسي غير متوفر. يساعد هذا التوافر على ضمان عدم فقدان البيانات. بعد تنشيط النسخة المتماثلة في وضع الاستعداد وتطبيق السجلات الثنائية، فإنه يأخذ دور الخادم الأساسي.
هل أحتاج إلى اتخاذ أي إجراء بعد تجاوز الفشل؟ تكون عمليات تجاوز الفشل شفافة تماما من تطبيق العميل. لستَ بحاجة إلى اتخاذ أي إجراء. يجب أن تستخدم التطبيقات فقط منطق إعادة المحاولة لاتصالاتها.
ماذا يحدث عندما لا أختار منطقة معينة لنسختي المتماثلة في وضع الاستعداد؟ هل يمكنني تغيير المنطقة لاحقا؟ إذا لم تختر منطقة، اختيار منطقة بشكل عشوائي. لن يكون هو المستخدم للخادم الأساسي. لتغيير المنطقة لاحقا، يمكنك تعيين التوفر العالي إلى معطل في جزء التوفر العالي، ثم تعيينه مرة أخرى إلى المنطقة الزائدة عن الحاجة واختيار منطقة.
هل النسخ المتماثل بين النسخ المتماثلة الأساسية والاحتياطية متزامن؟ يشبه النسخ المتماثل بين الأساسي والاستعداد الوضع شبه المتزامن في MySQL. عندما يتم الالتزام بمعاملة ، فإنها لا تلتزم بالضرورة بالاستعداد. ولكن عندما يكون الأساسي غير متوفر، يقوم الاستعداد بنسخ جميع تغييرات البيانات من الأساسي للتأكد من عدم فقدان البيانات.
هل هناك تجاوز للفشل في النسخة المتماثلة الاحتياطية لجميع حالات الفشل غير المخطط لها؟ إذا كان هناك عطل في قاعدة البيانات أو فشل عقدة، تتم إعادة تشغيل الجهاز الظاهري للخادم المرن على نفس العقدة. في الوقت نفسه ، يتم تشغيل تجاوز الفشل التلقائي. في حالة نجاح إعادة تشغيل الجهاز الظاهري للخادم المرن قبل انتهاء تجاوز الفشل، سيتم إلغاء عملية تجاوز الفشل. يعتمد تحديد الخادم الذي سيتم استخدامه كنسخة متماثلة أساسية على العملية التي تنتهي أولا.
هل هناك تأثير على الأداء عند استخدام HA؟ بالنسبة ل HA الزائدة عن الحاجة في المنطقة ، قد يكون هناك انخفاض بنسبة 5-10 في المائة في زمن الوصول إذا كان التطبيق متصلا بخادم قاعدة البيانات عبر مناطق توافر الخدمات حيث يكون زمن انتقال الشبكة أعلى نسبيا (2-4 مللي ثانية). بالنسبة ل HA في نفس المنطقة، نظرا لأن النسخة المتماثلة الأساسية والاحتياطية في نفس المنطقة، يكون تأخر النسخ المتماثل أقل. هناك زمن انتقال أقل بين خادم التطبيقات وخادم قاعدة البيانات عندما يكونان في نفس منطقة توافر الخدمات في Azure.
كيف تتم صيانة خادم HA الخاص بي؟ تحدث الأحداث المخطط لها مثل توسيع نطاق الحوسبة وترقيات الإصدارات الثانوية في الأساسي والاستعداد في نفس الوقت. يمكنك تعيين نافذة الصيانة المجدولة لخوادم HA كما تفعل مع الخوادم المرنة. سيكون مقدار وقت التوقف عن العمل هو نفسه وقت التوقف عن العمل لقاعدة بيانات Azure لخادم MySQL المرن عند تعطيل HA. إن استخدام آلية تجاوز الفشل لتقليل وقت التوقف عن العمل لخوادم HA موجود على خارطة الطريق الخاصة بنا وسيكون متاحا قريبا.
هل يمكنني إجراء استعادة نقطة زمنية (PITR) لخادم HA الخاص بي؟ يمكنك إجراء PITR لقاعدة بيانات Azure ممكنة من HA لخادم MySQL مرن إلى قاعدة بيانات Azure جديدة لخادم MySQL مرن تم تعطيل HA له. إذا تم إنشاء الخادم المصدر باستخدام HA الزائدة عن الحاجة للمنطقة، فيمكنك تمكين HA الزائدة عن الحاجة للمنطقة أو HA في نفس المنطقة على الخادم المستعاد لاحقا. إذا تم إنشاء الخادم المصدر باستخدام HA في نفس المنطقة، فيمكنك تمكين HA في نفس المنطقة فقط على الخادم المستعاد.
هل يمكنني تمكين HA على خادم بعد إنشاء الخادم؟ يجب تمكين HA الزائدة عن الحاجة عند إنشاء الخادم. يمكنك تمكين HA في نفس المنطقة بعد إنشاء الخادم. قبل تمكين HA في نفس المنطقة ، تأكد من تعيين معلمات الخادم enforce_gtid_consistency" و " gtid_mode" إلى ON
هل يمكنني تعطيل HA لخادم بعد إنشائه؟ يمكنك تعطيل HA على خادم بعد إنشائه. تتوقف الفوترة على الفور.
كيف يمكنني تخفيف وقت التوقف؟ يجب أن تكون قادرا على تخفيف وقت التوقف عن العمل لتطبيقك حتى عندما لا تستخدم HA. يمكن إجراء وقت تعطل الخدمة ، مثل التصحيحات المجدولة أو ترقيات الإصدارات الثانوية أو العمليات التي يبدأها العميل مثل توسيع نطاق الحوسبة أثناء نوافذ الصيانة المجدولة. للتخفيف من تأثير التطبيق على مهام الصيانة التي بدأها Azure، يمكنك جدولتها في يوم من أيام الأسبوع والوقت الذي يقلل من التأثير على التطبيق.
هل يمكنني استخدام نسخة متماثلة للقراءة لخادم يدعم HA؟ قراءة النسخ المتماثلة غير مدعومة لخوادم HA. هذه الميزة موجودة على خارطة الطريق الخاصة بنا، ونحن نعمل على إتاحتها قريبا.
هل يمكنني استخدام النسخ المتماثل للبيانات في خوادم HA؟ النسخ المتماثل للبيانات في غير مدعوم لخوادم HA. لكن النسخ المتماثل للبيانات لخوادم HA موجود على خارطة الطريق الخاصة بنا وسيكون متاحا قريبا. في الوقت الحالي، إذا كنت تريد استخدام النسخ المتماثل للبيانات للترحيل ، فيمكنك اتباع الخطوات التالية:
- قم بإنشاء الخادم مع تمكين HA الزائدة عن الحاجة للمنطقة.
- تعطيل HA.
- أكمل الخطوات اللازمة لإعداد النسخ المتماثل للبيانات في البيانات. (تأكد من وجود
gtid_modeنفس الإعداد على الخوادم المصدر والهدف.) - تقوم عمليات القطع اللاحقة بإزالة تكوين النسخ المتماثل للبيانات في البيانات.
- تمكين HA.
لتقليل وقت التوقف عن العمل، هل يمكنني الفشل في الوصول إلى خادم الاستعداد أثناء إعادة تشغيل الخادم أو أثناء التوسع لأعلى أو لأسفل؟ حاليا، عند إجراء عملية توسيع أو تصغير، يتم تحجيم وضع الاستعداد والأساسي في نفس الوقت. لذا فإن الفشل لا يساعد. إن السماح بتوسيع نطاق الاستعداد أولا ، متبوعا بتجاوز الفشل ، ثم توسيع نطاق الإعداد الأساسي موجود على خريطة الطريق الخاصة بنا ولكنه غير مدعوم بعد.
هل يمكننا تغيير وضع التوافر (المنطقة الزائدة عن الحاجة HA / نفس المنطقة) للخادم إذا قمت بإنشاء الخادم مع تمكين وضع HA المتكرر للمنطقة ، فيمكنك التغيير من HA الزائدة عن الحاجة إلى نفس المنطقة والعكس صحيح. لتغيير وضع التوافر، يمكنك تعيين التوفر العالي إلى معطل في جزء التوفر العالي، ثم تعيينه مرة أخرى إلى المنطقة الزائدة عن الحاجة أو المنطقة نفسها واختيار وضع التوفر العالي.
الخطوات التالية
- تعرف على استمرارية الأعمال.
- تعرف على التوافر العالي للمنطقة الزائدة عن الحاجة.
- تعرف على النسخ الاحتياطي والاسترداد.