إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تتيح لك قاعدة بيانات Azure ل MySQL Flexible Server تكوين قابلية الوصول العالية مع تجاوز الفشل التلقائي. يضمن هذا الحل أن الفشل لا يتسبب أبدا في فقدان البيانات الملتزم بها وأن قاعدة البيانات ليست نقطة فشل واحدة في بنية البرنامج الخاصة بك. عند تكوين قابلية الوصول العالية، يقوم الخادم المرن تلقائيا بتوفير نسخة متماثلة احتياطية وإدارتها. أنت تدفع مقابل الحوسبة والتخزين المتوفرين لكل من النسخ المتماثلة الأساسية والثانوية. يتوفر نموذجين معماريان عالي التوافر:
توفر عالي للحاجة في المنطقة. يوفر هذا الخيار عزلا كاملا وتكرارا للبنية الأساسية عبر مناطق توفر متعددة. إنه يوفر أعلى مستوى من التوفر، ولكنه يتطلب منك تكوين تكرار التطبيق عبر المناطق. اختر قابلية الوصول العالية المتكررة للمنطقة عندما تريد الحماية من أي فشل في البنية الأساسية في منطقة التوفر وعندما يكون زمن الانتقال عبر منطقة التوفر مقبولا. يمكنك تمكين قابلية الوصول العالية المتكررة للمنطقة فقط عند إنشاء الخادم. تتوفر قابلية الوصول العالية المتكررة في المنطقة في مجموعة فرعية من مناطق Azure حيث تدعم المنطقة العديد من مناطق التوفر ومشاركات ملفات Premium المكررة في المنطقة.
توافر عال محلي زائد. يوفر هذا الخيار تكرار البنية الأساسية مع زمن انتقال أقل للشبكة لأن الخوادم الأساسية والاحتياطية موجودة في نفس منطقة التوفر. يوفر قابلية وصول عالية دون الحاجة إلى تكوين تكرار التطبيق عبر المناطق. أختر قابلية الوصول العالية المتكررة محليا عندما تريد تحقيق أعلى مستوى من الاتاحة داخل منطقة إتاحة واحدة بأقل زمن انتقال للشبكة. تتوفر قابلية الوصول العالية المحلية الزائدة عن الحاجة في جميع مناطق Azure حيث يمكنك استخدام قاعدة بيانات Azure لخادم MySQL المرن.
بنية قابلية الوصول العالية (HA) المتكررة في المنطقة
عند نشر خادم ذو قابلية وصول عالية متكررة للمنطقة، يقوم Azure بإنشاء خادمين:
- خادم أساسي في منطقة توفر واحدة.
- خادم نسخة متماثلة احتياطية في منطقة توفر أخرى لنفس منطقة Azure. يحتوي خادم النسخة المتماثلة الاحتياطية على نفس تكوين الخادم الأساسي، بما في ذلك طبقة الحساب وحجم الحوسبة وحجم التخزين وتكوين الشبكة.
يمكنك اختيار منطقة التوفر لكل من الخادم الأساسي والنسخة المتماثلة الاحتياطية. يؤدي وضع خوادم قاعدة البيانات الاحتياطية والتطبيقات البديلة في نفس المنطقة إلى تقليل زمن الانتقال. كما أنه يساعدك على الاستعداد لحالات التعافي من الكوارث وسيناريوهات "تقسيم المنطقة".
تتم استضافة ملفات البيانات والسجلات في منطقة تخزين متكررة (ZRS). يقرأ الخادم الاحتياطي باستمرار ملفات السجل ويعيد تشغيلها من حساب تخزين الخادم الأساسي، والذي يحميه النسخ المتماثل على مستوى التخزين.
في حالة حدوث تجاوز الفشل:
- يتم تنشيط النسخة المتماثلة الاحتياطية.
- تستمر ملفات السجل الثنائية للخادم الأساسي في التطبيق على الخادم الاحتياطي لإحضاره عبر الإنترنت إلى آخر معاملة ملتزم بها على الخادم الأساسي.
يمكن الوصول إلى السجلات في ZRS حتى في حال عدم توفر الخادم الأساسي. يساعد هذا التوفر على ضمان عدم فقدان البيانات. بعد تنشيط النسخة المتماثلة الاحتياطية وتطبيق السجلات الثنائية، يأخذ خادم النسخة المتماثلة الاحتياطية الحالي دور الخادم الأساسي. يتم تحديث DNS بحيث تكون اتصالات العميل مباشرة إلى الأساسي الجديد عند إعادة الاتصال بالعميل. يكون تجاوز الفشل شفافاً تماماً من تطبيق العميل ولا يتطلب منك أي إجراء. ثم يعيد حل قابلية الوصول العالية الخادم الأساسي القديم عندما يكون ذلك ممكناً ويضعه في وضع الاستعداد.
يمكنك استخدام اسم خادم قاعدة البيانات لتوصيل التطبيقات بالخادم الأساسي. لا يعرض الحل معلومات النسخة المتماثلة الاحتياطية للوصول المباشر. يتم الاعتراف بعمليات الكتابة والالتزامات بعد مسح ملفات السجل في ZRS للخادم الأساسي. نظراً لتقنية النسخ المتماثل للمزامنة المستخدمة في تخزين ZRS، يمكنك توقع زيادة زمن انتقال بنسبة 5-10 بالمائة لعمليات الكتابة والالتزامات الخاصة بالتطبيق.
يتم إجراء النسخ الاحتياطية التلقائية، سواء اللقطات أو النسخ الاحتياطية للسجلات، على مساحة تخزين متكررة من خادم قاعدة البيانات الأساسي.
بنية قابلية الوصول العالية (HA) المحلية المتكررة
عند نشر خادم باستخدام HAع محلي متكرر، يمكنك إنشاء خادمين في نفس المنطقة:
- خادم أساسي
- خادم نسخة احتياطي له نفس تكوين الخادم الأساسي (طبقة الحساب، وحجم الحساب، وحجم التخزين، وتكوين الشبكة)
يوفر الخادم الاحتياطي تكرار البنية الأساسية مع جهاز ظاهري منفصل (حساب). يقلل هذا التكرار من وقت تجاوز الفشل وزمن انتقال الشبكة بين التطبيق وخادم قاعدة البيانات بسبب الموقع المشترك.
تتم استضافة ملفات البيانات والسجلات في التخزين المحلي المتكرر (LRS). يقرأ الخادم الاحتياطي باستمرار ملفات السجل ويعيد تشغيلها من حساب تخزين الخادم الأساسي، المحمي بواسطة النسخ المتماثل على مستوى التخزين.
في حالة حدوث تجاوز الفشل:
- يتم تنشيط النسخة المتماثلة الاحتياطية.
- تستمر ملفات السجل الثنائية للخادم الأساسي في التطبيق على الخادم الاحتياطي لإحضاره عبر الإنترنت إلى آخر معاملة ملتزم بها على الخادم الأساسي.
يمكن الوصول إلى السجلات في LRS حتى في حال عدم توفر الخادم الأساسي. يساعد هذا التوفر على ضمان عدم فقدان البيانات. بعد تنشيط النسخة المتماثلة الاحتياطية وتطبيق السجلات الثنائية، تأخذ النسخة المتماثلة البديلة الحالية دور الخادم الأساسي. يتم تحديث DNS لإعادة توجيه الاتصالات إلى الخادم الأساسي الجديد عندما يعيد العميل الاتصال. يكون تجاوز الفشل شفافاً تماماً من تطبيق العميل ولا يتطلب منك أي إجراء. ثم يعيد حل قابلية الوصول العالية الخادم الأساسي القديم عندما يكون ذلك ممكناً ويضعه في وضع الاستعداد.
يقوم اسم خادم قاعدة البيانات بتوصيل التطبيقات بالخادم الأساسي. لا يتم عرض معلومات النسخة المتماثلة الاحتياطية للوصول المباشر. يتم الاعتراف بعمليات الكتابة والالتزامات بعد مسح ملفات السجل في LRS للخادم الأساسي. نظراً لوجود النسخة المتماثلة الأساسية والنسخة الاحتياطية في نفس المنطقة، فهناك تأخر أقل في النسخ المتماثل وزمن انتقال أقل بين خادم التطبيق وخادم قاعدة البيانات. لا يوفر الإعداد المحلي المتكرر قابلية وصول عالية عندما تكون البنى التحتية التابعة معطلة لمنطقة التوفر المحددة. هناك وقت تعطل حتى تعود جميع الخدمات التابعة إلى الاتصال بالإنترنت لمنطقة التوفر هذه.
يتم إجراء النسخ الاحتياطية التلقائية، سواء اللقطات أو النسخ الاحتياطية للسجلات، على مساحة تخزين متكررة محلياً من خادم قاعدة البيانات الأساسي.
إشعار
لكل من قابلية الارتفاع الاحتياطية في المنطقة والتكرار المحلي:
- في حالة حدوث عطل، يعتمد الوقت اللازم للنسخة المتماثلة الاحتياطية لتولي دور الأساسي على الوقت المستغرق لإعادة تشغيل السجل الثنائي من حساب التخزين الأساسي إلى وضع الاستعداد. لتقليل وقت تجاوز الفشل، استخدم المفاتيح الأساسية على جميع الجداول. تستغرق أوقات تجاوز الفشل عادة ما بين 60 و120 ثانية.
- خادم الاستعداد غير متاح لعمليات القراءة أو الكتابة. إنه وضع الاستعداد السلبي لتمكين تجاوز الفشل السريع.
- استخدم دائماً اسم مجال مؤهل بالكامل (FQDN) للاتصال بخادمك الأساسي. تجنب استخدام عنوان IP للاتصال. في حالة حدوث تجاوز الفشل، بعد تبديل أدوار الخادم الأساسي والاحتياطي، قد يتغير سجل DNS A. يمنع هذا التغيير التطبيق من الاتصال بالخادم الأساسي الجديد إذا تم استخدام عنوان IP في سلسلة الاتصال.
عملية تجاوز الفشل
أثناء عملية تجاوز الفشل في قاعدة بيانات Azure ل MySQL، يتحول النظام تلقائيا من الخادم الأساسي إلى النسخة المتماثلة الاحتياطية. يضمن هذا المفتاح الاستمرارية ويقلل من وقت التوقف عن العمل. عندما يكتشف النظام عطلا، فإنه يروج للنسخة المتماثلة الاحتياطية لتصبح الخادم الأساسي الجديد. يطبق النظام ملفات السجل الثنائي من الخادم الأساسي الأصلي إلى النسخة المتماثلة الاحتياطية. تقوم هذه العملية بمزامنة النسخة المتماثلة الاحتياطية مع آخر معاملة ملتزم بها وتضمن عدم فقدان البيانات. يساعد هذا الانتقال السلس في الحفاظ على التوافر العالي وموثوقية خدمة قاعدة البيانات.
إشعار
لتقليل الاعتماد على وقت تجاوز الفشل على التخزين المؤقت لنظام أسماء النطاقات، اعتبارا من أكتوبر 2025، ستتبنى جميع خوادم قابلية الوصول العالية الجديدة التي تم إنشاؤها باستخدام الوصول العام أو الارتباط الخاص البنية الجديدة التي تتميز ب SLB مخصص لكل خادم HA. من خلال إدارة مسار حركة مرور بيانات MySQL، يلغي SLB الحاجة إلى تغييرات DNS أثناء تجاوز الفشل ويحسن أداء تجاوز الفشل بشكل كبير. يعيد توجيه نسبة استخدام الشبكة إلى المثيل الأساسي الحالي أثناء تجاوز الفشل باستخدام قواعد موازنة التحميل. سيتم ترحيل الخوادم الحالية ذات الوصول العام أو الارتباط الخاص تدريجيا لتقليل التأثير. يمكن للعملاء الذين يفضلون الترحيل المبكر تعطيل قابلية الوصول العالية وإعادة تمكينها. هذه الميزة غير مدعومة للخوادم التي تستخدم الوصول الخاص مع تكامل الشبكة الظاهرية.
مخطط له: تجاوز الفشل الإجباري
تمكنك قاعدة بيانات Azure لخادم MySQL المرن من فرض تجاوز الفشل يدويا. تتيح لك هذه الإمكانية اختبار الوظائف باستخدام سيناريوهات التطبيق الخاصة بك وتساعدك على الاستعداد لانقطاع.
يؤدي تجاوز الفشل القسري إلى تشغيل تجاوز الفشل الذي ينشط النسخة المتماثلة الاحتياطية لتصبح الخادم الأساسي بنفس اسم خادم قاعدة البيانات عن طريق تحديث سجل DNS. تتم إعادة تشغيل الخادم الأساسي الأصلي والتبديل إلى النسخة المتماثلة الاحتياطية. تنقطع اتصالات العميل وتحتاج إلى إعادة الاتصال لاستئناف عملياتها.
يعتمد وقت تجاوز الفشل الكلي على حجم العمل الحالي ونقطة التحقق الأخيرة. بشكل عام ، يستغرق الأمر ما بين 60 و 120 ثانية.
إشعار
يتم إنشاء حدث Azure Resource Health أثناء تجاوز الفشل المخطط له. يمثل الحدث وقت تجاوز الفشل الذي لا يتوفر خلاله الخادم. يمكنك رؤية الأحداث التي تم تشغيلها عند تحديدها في صحة المورد في الجزء الأيمن. تمثل الحالة تجاوز الفشل الذي بدأه المستخدم أو يدويا على أنها "غير متوفرة" وعلامة عليها على أنها "مخططة". مثال - "تم تشغيل عملية تجاوز الفشل من قبل مستخدم معتمد (مخطط له)". إذا ظل موردك في هذه الحالة لفترة طويلة ، فافتح تذكرة دعم ونحن نساعدك.
غير مخطط له: تجاوز الفشل التلقائي
يمكن أن يحدث تعطل الخدمة غير المخطط له بسبب أخطاء البرامج أو أعطال البنية الأساسية ، مثل فشل الحوسبة أو الشبكة أو التخزين. يمكن أن يؤثر انقطاع التيار الكهربائي أيضا على توفر قاعدة البيانات. إذا أصبحت قاعدة البيانات غير متوفرة، يتوقف النسخ المتماثل إلى النسخة المتماثلة الاحتياطية، وتصبح النسخة المتماثلة الاحتياطية هي قاعدة البيانات الأساسية. تحدث تحديثات DNS، ويقوم العملاء بإعادة الاتصال بخادم قاعدة البيانات، واستئناف عملياتهم.
عادة ما يتراوح وقت تجاوز الفشل الإجمالي بين 60 و 120 ثانية. ومع ذلك، استنادا إلى النشاط في خادم قاعدة البيانات الأساسي في وقت تجاوز الفشل (مثل المعاملات الكبيرة ووقت الاسترداد)، قد يستغرق تجاوز الفشل وقتا أطول.
إشعار
يتم إنشاء حدث Azure Resource Health أثناء تجاوز الفشل غير المخطط له. يمثل الحدث وقت تجاوز الفشل عندما يكون الخادم غير متوفر. يمكنك رؤية الأحداث التي تم تشغيلها عند تحديد صحة المورد في الجزء الأيمن. يظهر تجاوز الفشل التلقائي حالة "غير متوفر" ويتم تمييزه على أنه "غير مخطط".
على سبيل المثال، غير متوفر: تم تشغيل عملية تجاوز الفشل تلقائيا (غير مخطط لها). إذا بقي موردك في هذه الحالة لفترة طويلة ، فافتح تذكرة دعم ونحن نساعدك.
كيف يعمل الكشف التلقائي عن تجاوز الفشل في وحدات الخدمة حيث تم تمكين قابلية الوصول العالية
يحتوي كل من الخادم الأساسي والخادم الثانوي على نقطتي نهاية للشبكة:
- نقطة نهاية العميل: يقوم العملاء بتوصيل الاستعلامات وتشغيلها على المثيل باستخدام نقطة النهاية هذه.
- نقطة نهاية الإدارة: تُستخدم داخلياً لاتصالات الخدمة بمكونات الإدارة وللاتصال بتخزين الواجهة الخلفية.
يقوم مكون مراقبة السلامة بإجراء الفحوصات التالية باستمرار:
- تقوم الشاشة باختبار اتصال نقطة نهاية شبكة إدارة العقدة. إذا فشل هذا الفحص مرتين متتاليتين، فإنه يؤدي إلى تشغيل عملية تجاوز الفشل التلقائية. يعالج فحص السلامة هذا سيناريوهات مثل عدم توفر العقدة أو عدم الاستجابة بسبب مشكلات نظام التشغيل ومشكلات الشبكات بين مكونات الإدارة والعقد والمشكلات المماثلة.
- تقوم الشاشة بتشغيل استعلام بسيط على المثيل. إذا فشلت الاستعلامات في التشغيل، يتم تشغيل تجاوز الفشل التلقائي. يعالج فحص السلامة هذا سيناريوهات مثل تعطل برنامج MySQL الخفي أو توقفه أو تعليقه ومشكلات تخزين الواجهة الخلفية والمشكلات المماثلة.
إشعار
لا يراقب التحقق من السلامة مشكلات الشبكة بين التطبيق ونقطة نهاية شبكة العملاء (الوصول الخاص/العام). يمكن أن تحدث هذه المشكلات في مسار الشبكة أو على نقطة النهاية أو في مشكلات DNS من جانب العميل. إذا كنت تستخدم الوصول الخاص، فتأكد من أن قواعد NSG للشبكة الظاهرية لا تمنع الاتصال بنقطة نهاية شبكة عميل المثيل على المنفذ 3306. للوصول العام، تأكد من تعيين قواعد جدار الحماية والسماح بحركة مرور الشبكة على المنفذ 3306 (إذا كان مسار الشبكة يحتوي على أي جدران حماية أخرى). تحتاج أيضا إلى الاهتمام بدقة DNS من جانب تطبيق العميل.
مراقبة التوافر العالي
للتحقق من حالة تكوين قابلية الوصول العالية للخادم، استخدم حالة قابلية الوصول العالية في جزء قابلية الوصول العالية للخادم في المدخل.
| الحالة | الوصف |
|---|---|
| غير ممكن | لم يتم تمكين قابلية الوصول العالية. |
| بيانات النسخ المتماثل |
يتزامن الخادم الاحتياطي مع الخادم الأساسي أثناء توفير الخادم عالي التوفر أو عند تمكين خيار التوفر العالي. |
| تجاوز الفشل |
يتعذر خادم قاعدة البيانات من الأساسي إلى الاستعداد. |
| صحي | تم تمكين خيار التوفر العالي. |
| إزالةStandby | عملية الحذف جارية عند تعطيل خيار التوفر العالي. |
لمراقبة سلامة الخادم عالي التوفر، استخدم المقاييس التالية.
| اسم عرض المقياس | متري | الوحدة | الوصف |
|---|---|---|---|
حالة HA IO |
ha_io_running | المنطقة | تعرض حالة قابلية الوصول IO العالية حالة النسخ المتماثل ل HA. قيمة المقياس هي 1 إذا كان مؤشر ترابط الإدخال/الإخراج قيد التشغيل و 0 إذا لم يكن كذلك. |
| حالة HA SQL | ha_sql_running | المنطقة | تعرض حالة HA SQL حالة النسخ المتماثل ل HA. قيمة المقياس هي 1 إذا كان مؤشر ترابط SQL قيد التشغيل و 0 إذا لم يكن كذلك. |
| تأخر النسخ المتماثل HA | replication_lag | ثوانٍ | تأخر النسخ المتماثل هو عدد الثوان التي يكون فيها الاستعداد متأخرا في إعادة تشغيل المعاملات المستلمة على الخادم الأساسي. |
القيود
ضع الاعتبارات التالية في الاعتبار عند استخدام قابلية الوصول العالية:
يمكنك تكوين قابلية الوصول العالية الزائدة عن الحاجة في المنطقة فقط أثناء إنشاء الخادم.
لا تدعم طبقة الحوسبة القابلة للاندفاع قابلية الوصول العالية.
تؤدي إعادة تشغيل خادم قاعدة البيانات الأساسية لتطبيق تغييرات المعلمات الثابتة أيضا إلى إعادة تشغيل النسخة المتماثلة الاحتياطية.
يقوم الحل بتشغيل وضع GTID لأنه يستخدم GTID. تحقق مما إذا كان حِمل العمل لديك به قيود أو حدود على النسخ باستخدام GTIDs.
إشعار
يتم تمكين التخزين التلقائي بشكل افتراضي لخادم تم تكوينه عالي التوفر ولا يمكن تعطيله.
الفحوصات الصحية
عند تكوين قابلية الوصول العالية (HA) لقاعدة بيانات Azure ل MySQL، تلعب عمليات التحقق من السلامة دورا مهما في الحفاظ على موثوقية قاعدة البيانات وأدائها. تراقب هذه الفحوصات باستمرار حالة وصحة كل من النسخ المتماثلة الأساسية والاحتياطية ، مما يضمن اكتشافها لأي مشكلات على الفور. من خلال تتبع المقاييس المختلفة مثل استجابة الخادم وتأخر النسخ المتماثل واستخدام الموارد ، تساعد عمليات التحقق من السلامة على ضمان إمكانية تنفيذ عمليات تجاوز الفشل بسلاسة ، مما يقلل من وقت التوقف عن العمل ويمنع فقدان البيانات. تعد عمليات التحقق من الصحة المكونة بشكل صحيح ضرورية لتحقيق المستوى المطلوب من التوفر والمرونة في إعداد قاعدة البيانات.
مراقبة الصحة
يمكنك مراقبة صحة إعداد قابلية الوصول العالية من خلال مدخل Microsoft Azure. تتضمن المقاييس الرئيسية التي يجب ملاحظتها ما يلي:
- استجابة الخادم: يشير إلى ما إذا كان الخادم الأساسي قابلا للوصول.
- تأخر النسخ المتماثل: يقيس التأخير بين النسخ المتماثلة الأساسية والاستعدادية، ما يضمن تناسق البيانات.
- استخدام الموارد: يراقب استخدام وحدة المعالجة المركزية والذاكرة والتخزين لمنع الاختناقات.