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

  • مقالة

ينطبق على: قاعدة بيانات Azure لـMySQL - خادم مرن

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

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

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

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

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

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

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

رسم تخطيطي يوضح بنية قابلية الوصول العالية المتكررة.

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

إذا كان هناك تجاوز فشل:

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

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

يُستخدم اسم خادم قاعدة البيانات لتوصيل التطبيقات بالخادم الأساسي. لا يتم عرض معلومات النسخة المتماثلة الاحتياطية للوصول المباشر. يتم الاعتراف بعمليات الكتابة والالتزامات بعد مسح ملفات السجل في ZRS للخادم الأساسي. نظراً لتقنية النسخ المتماثل للمزامنة المستخدمة في تخزين ZRS، يمكنك توقع زيادة زمن انتقال بنسبة 5-10 بالمائة لعمليات الكتابة والالتزامات الخاصة بالتطبيق.

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

بنية قابلية الوصول العالية في نفس المنطقة

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

  • خادم أساسي
  • خادم نسخة احتياطي له نفس تكوين الخادم الأساسي (طبقة الحساب، وحجم الحساب، وحجم التخزين، وتكوين الشبكة)

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

رسم تخطيطي يوضح بنية قابلية الوصول العالية في نفس المنطقة.

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

إذا كان هناك تجاوز فشل:

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

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

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

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

إشعار

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

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

عملية تجاوز الفشل

مخطط له: تجاوز الفشل الإجباري

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

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

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

إشعار

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

غير مخطط له: تجاوز الفشل التلقائي

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

من المتوقع أن يكون الوقت الإجمالي لتجاوز الفشل ما بين 60 و120 ثانية. ولكن، بناءً على النشاط في خادم قاعدة البيانات الأساسي في وقت تجاوز الفشل (مثل العمليات الكبيرة ووقت الاسترداد)، قد يستغرق تجاوز الفشل وقتاً أطول.

إشعار

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

كيف يعمل الكشف التلقائي عن تجاوز الفشل في وحدات الخدمة حيث تم تمكين قابلية الوصول العالية

يحتوي الخادم الأساسي والخادم الثانوي على نقطتي نهاية للشبكة،

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

يقوم مكون مراقبة الحالة بإجراء الفحوصات التالية بشكل مستمر

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

إشعار

في حال وجود أي مشكلة في الشبكة بين التطبيق ونقطة نهاية شبكة العملاء (وصول خاص/عام)، إما في مسار الشبكة أو في نقطة النهاية أو مشكلات DNS في جانب العميل، فإن التحقق من الحالة لا يراقب هذا السيناريو. إذا كنت تستخدم وصولاً خاصاً، فتأكد من أن قواعد NSG الخاصة بشبكة VNet لا تمنع الاتصال بنقطة نهاية شبكة عملاء المثيل على المنفذ 3306. للوصول العام، تأكد من تعيين قواعد جدار الحماية وأن نسبة استخدام الشبكة مسموح بها على المنفذ 3306 (إذا كان مسار الشبكة يحتوي على أي جدران حماية أخرى). يجب أيضاً الاهتمام بحل DNS من جانب تطبيق العميل.

مراقبة قابلية الوصول العالية

يمكن استخدام حالة التوفر العالي الموجودة في جزء التوفر العالي للخادم في المدخل لتحديد حالة تكوين قابلية الوصول العالية للخادم.

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

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

اسم عرض المقياس Metric الوحدة ‏‏الوصف
حالة HA IO ha_io_running الولاية تشير حالة HA IO إلى حالة النسخ المتماثل HA. قيمة القياس هي 1 إذا كان مؤشر ترابط الإدخال/الإخراج قيد التشغيل و0 إن لم يكن.
حالة HA SQL ha_sql_running الولاية تشير حالة HA SQL إلى حالة النسخ المتماثل HA. قيمة القياس هي 1 إذا كان مؤشر ترابط SQL قيد التشغيل و0 إن لم يكن.
تأخر النسخ المتماثل HA replication_lag ثوانٍ تأخر النسخ المتماثل هو عدد الثوان التي يكون فيها الاستعداد متأخرا في إعادة تشغيل المعاملات المستلمة على الخادم الأساسي.

القيود

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

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

إشعار

إذا كنت تقوم بتمكين قابلية الوصول العالية لنفس المنطقة بعد إنشاء وحدة الخدمة، فأنت بحاجة للتأكد من معلمات وحدة الخدمة forcece_gtid_consistency و"gtid_mode" مضبوطة على ON قبل تمكين قابلية الوصول العالية.

إشعار

يتم تمكين التخزين التلقائي افتراضيا لخادم مكون عالي التوفر ولا يمكن تعطيله.

الأسئلة الشائعة (FAQ)

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

    يمكن العثور على معلومات اتفاقية مستوى الخدمة لقاعدة بيانات Azure لخادم MySQL المرن في اتفاقية مستوى الخدمة لقاعدة بيانات Azure ل MySQL.

  • كيف تتم محاسبتي على الخوادم ذات قابلية الوصول العالية؟ الخوادم التي تم تمكينها باستخدام قابلية الوصول العالية لها نسخة متماثلة أولية وثانوية. يمكن أن تكون النسخة المتماثلة الثانوية في نفس المنطقة أو المنطقة المتكررة. تتم محاسبتك على الحساب الموفر والتخزين لكل من النسخة المتماثلة الأساسية والثانوية. على سبيل المثال، إذا كان لديك حساب أساسي يحتوي على 4 vCores و512 غيغابايت من سعة التخزين المتوفرة، فستحتوي النسخة المتماثلة الثانوية أيضاً على 4 vCores و512 غيغابايت من مساحة التخزين المتوفرة. ستتم محاسبة خادم قابلية الوصول العالية المتكررة في منطقتك مقابل 8 vCores و1،024 GB للتخزين. اعتماداً على حجم تخزين النسخ الاحتياطي، قد تتم محاسبتك أيضاً على تخزين النسخ الاحتياطي.

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

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

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

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

  • هل النسخ المتماثل بين النسخ المتماثلة الأساسية والنسخ المتماثلة في وضع الاستعداد متزامن؟
    يشبه النسخ المتماثل بين النسخ المتماثلة الأساسية والنسخ المتماثلة في وضع الاستعداد semisynchronous mode في MySQL. عندما يتم الالتزام بالعملية، فإنها لا تلتزم بالضرورة في النسخة المتماثلة في وضع الاستعداد. ولكن في حال عدم توفر الخادم الأساسي، تقوم النسخة المتماثلة في وضع الاستعداد بنسخ جميع تغييرات البيانات من الأساسي للتأكد من عدم فقدان البيانات.

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

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

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

  • هل يمكنني إجراء استعادة نقطة زمنية (PITR) لخادم قابلية الوصول العالية الخاص بي؟
    يمكنك القيام ب PITR لمثيل خادم مرن ل Azure Database for MySQL يدعم قابلية الوصول العالية لمثيل خادم Azure Database for MySQL المرن الذي تم تعطيل HA فيه. إذا تم تكوين وحدة الخدمة المصدر باستخدام قابلية وصول عالية متكررة للمنطقة، يمكنك إتاحة قابلية وصول عالية متكرر للمنطقة أو قابلية الوصول العالية في نفس المنطقة على وحدة الخدمة المستعادة فيما بعد. إذا تم تكوين وحدة الخدمة المصدر باستخدام قابلية الوصول العالية من نفس المنطقة، يمكنك تمكين قابلية الوصول العالية لنفس المنطقة فقط على وحدة الخدمة المستعادة.

  • هل يمكنني تمكين قابلية الوصول العالية على الخادم بعد تكوين الخادم؟
    يجب تمكين قابلية الوصول العالية المتكررة في المنطقة عند تكوين وحدة الخدمة. يمكنك إتاحة قابلية الوصول العالية لنفس المنطقة بعد تكوين وحدة الخدمة. قبل تمكين قابلية الوصول العالية لنفس المنطقة ​​تأكد من أن معلمات الخادم enforce_gtid_consistency” و“gtid_mode” مضبوطة على ON

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

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

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

  • هل يمكنني استخدام النسخ المتماثل للبيانات في وحدات خدمة قابلية الوصول العالية؟
    يتوفر دعم النسخ المتماثل للبيانات للخادم الممكن للإتاحة العالية (HA) فقط من خلال النسخ المتماثل المستند إلى GTID. يتوفر الإجراء المخزن للنسخ المتماثل باستخدام GTID على جميع الخوادم الممكنة ل HA بالاسم mysql.az_replication_with_gtid.

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

  • هل يمكننا تغيير وضع الإتاحة (قابلية الوصول العالية المتكررة في المنطقة/نفس المنطقة) للخادم
    إذا قمت بإنشاء الخادم مع تمكين وضع قابلية الوصول العالية المتكررة في المنطقة، يمكنك التغيير من قابلية الوصول العالية المتكررة في المنطقة إلى نفس المنطقة والعكس صحيح. لتغيير وضع التوفر، يمكنك تعيين High Availability إلى Disabled في جزء High Availability، ثم إعادة تعيينه مرة أخرى إلى Zone Redundant or same-zone واختر High Availability Mode.

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