إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
Azure SQL Managed Instance هو محرك قاعدة بيانات يعمل كخدمة (PaaS) يدار بالكامل بالكامل. يوفر ما يقرب من 100 ميزة% التوافق مع SQL Server. يتعامل Azure SQL Managed Instance مع معظم وظائف إدارة قواعد البيانات مثل الترقية، والتحديثات، والنسخ الاحتياطية، والمراقبة دون تدخل المستخدم. يعمل على أحدث إصدار مستقر من محرك قاعدة بيانات SQL Server ونظام تشغيل مصحح مع توفر عالي مدمج.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
تصف هذه المقالة كيفية جعل نسخة Azure SQL المدارة مقاومة لمجموعة متنوعة من الانقطاعات والمشاكل المحتملة، بما في ذلك الأعطال المؤقتة، انقطاعات مناطق التوفر، وانقطاعات المناطق. كما يشرح كيف يمكنك استخدام النسخ الاحتياطية للاسترداد من أنواع أخرى من المشاكل، وكيفية التعامل مع صيانة الخدمة، ويسلط الضوء على بعض المعلومات الأساسية حول اتفاقية مستوى خدمة المثيلات المدارة في Azure SQL (SLA).
توصيات نشر الإنتاج للموثوقية
بالنسبة لمعظم عمليات توزيع الإنتاج لمثيل SQL المدار، ضع في اعتبارك التوصيات التالية:
اتبع الإرشادات الواردة في قائمة التحقق من قابلية الوصول العالية والتعافي من الكوارث (DR).
تمكين تكرار المنطقة.
قم بتكوين النسخ الاحتياطية التلقائية، واستخدم التخزين المتكرر للمنطقة (ZRS) أو التخزين المتكرر جغرافيا (GRS) للنسخ الاحتياطية.
خطط لاختبار النسخ الاحتياطية وعملية الاستعادة بانتظام.
نظرة عامة على بنية الموثوقية
تعمل مثيلات SQL المدارة للأغراض العامة على عقدة واحدة يديرها Azure Service Fabric . عندما تتم ترقية محرك قاعدة البيانات أو نظام التشغيل، أو يتم اكتشاف فشل، يعمل SQL Managed Instance مع Service Fabric لنقل عملية محرك قاعدة البيانات عديمة الحالة إلى عقدة حساب أخرى عديمة الحالة تحتوي على سعة خالية كافية. يتم تخزين ملفات قاعدة البيانات في Azure Blob Storage، الذي يحتوي على ميزات التكرار المضمنة. يتم فصل البيانات وملفات السجل عن عقدة الحساب الأصلية وإرفاقها بعملية محرك قاعدة البيانات التي تمت تهيئتها حديثا.
تستخدم مثيلات SQL المدارة للأعمال الهامة نسخا متماثلة متعددة في نظام مجموعة. تتضمن المجموعة نوعين من النسخ المتماثلة:
نسخة متماثلة أساسية واحدة يمكن الوصول إليها لأحمال عمل العملاء للقراءة والكتابة
ما يصل إلى خمس نسخ ثانوية متماثلة (الحوسبة والتخزين) تحتوي على نسخ من البيانات
تقوم النسخة المتماثلة الأساسية بدفع التغييرات بشكل مستمر ومتتابع إلى النسخ المتماثلة الثانوية، مما يضمن استمرار البيانات على عدد كاف من النسخ المتماثلة الثانوية قبل تنفيذ كل حركة. تضمن هذه العملية أنه في حالة عدم توفر النسخة المتماثلة الأساسية أو نسخة متماثلة ثانوية قابلة للقراءة، تتوفر نسخة متماثلة متزامنة بالكامل دائما لتجاوز الفشل.
يبدأ SQL Managed Instance وService Fabric تجاوز الفشل بين النسخ المتماثلة. بعد أن تصبح النسخة المتماثلة الثانوية هي النسخة المتماثلة الأساسية الجديدة، يتم إنشاء نسخة متماثلة ثانوية أخرى للتأكد من أن نظام المجموعة يحتوي على عدد كاف من النسخ المتماثلة للحفاظ على النصاب القانوني. بعد اكتمال تجاوز الفشل، تتم إعادة توجيه اتصالات Azure SQL تلقائيا إلى النسخة المتماثلة الأساسية الجديدة، أو النسخة المتماثلة الثانوية القابلة للقراءة، استنادا إلى سلسلة الاتصال.
التكرار
بشكل افتراضي، يحقق SQL Managed Instance التكرار عن طريق نشر عقد الحوسبة والبيانات عبر مركز بيانات واحد في المنطقة الأساسية. يحمي هذا الأسلوب بياناتك خلال أوقات التوقف المتوقعة وغير المتوقعة التالية:
عمليات الإدارة التي بدأها العميل والتي تؤدي إلى تعطل قصير
عمليات صيانة الخدمة
انقطاع التيار الكهربائي أو الشبكة على نطاق صغير
المشكلات وانقطاع مركز البيانات التي تتضمن المكونات التالية:
الحامل الذي تعمل فيه الآلات التي تشغل خدمتك
الجهاز الفعلي الذي يستضيف الجهاز الظاهري (VM) الذي يقوم بتشغيل محرك قاعدة بيانات SQL.
الجهاز الظاهري الذي يقوم بتشغيل SQL Database Engine
مشاكل مع محرك قاعدة بيانات SQL
انقطاعات محلية محتملة غير مخطط لها
لمزيد من المعلومات حول كيفية توفير SQL Managed Instance التكرار، راجع التوفر من خلال التكرار المحلي والمنطقة.
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
يعالج SQL Managed Instance تلقائيا مهام الخدمة الهامة، مثل التصحيح والنسخ الاحتياطية وترقيات Windows وSQL Database Engine. كما أنه يتعامل مع الأحداث غير المخطط لها مثل الأجهزة الأساسية أو البرامج أو فشل الشبكة. يمكن أن يسترد SQL Managed Instance بسرعة حتى في أخطر الظروف، مما يضمن توفر بياناتك دائما. لا يلاحظ معظم المستخدمين أن الترقيات يتم إجراؤها باستمرار.
عندما يتم تصحيح مثيل أو فشله ، يكون لوقت التوقف عن العمل تأثير ضئيل إذا كنت تستخدم منطق إعادة المحاولة في التطبيق الخاص بك. يمكنك اختبار مرونة التطبيق الخاص بك في مواجهة الأخطاء العابرة.
المرونة في مواجهة حالات فشل منطقة التوفر
ملاحظة
تكرار المنطقة غير متاح حاليا لطبقة خدمة الأغراض العامة من الجيل التالي.
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
عند تمكين تكوين متكرر للمنطقة ، يمكنك التأكد من أن مثيل SQL المدار مرن لمجموعة كبيرة من حالات الفشل، بما في ذلك الانقطاعات الكارثية لمركز البيانات، دون أي تغييرات في منطق التطبيق.
يحقق SQL Managed Instance تكرار المنطقة عن طريق وضع عقد الحوسبة عديمة الحالة في مناطق توفر مختلفة. يعتمد على ZRS ذو الحالة المرفق بأي عقدة تحتوي حاليا على عملية SQL Database Engine النشطة. في حالة حدوث انقطاع، تصبح عملية SQL Database Engine نشطة على إحدى عقد الحوسبة عديمة الحالة، والتي تصل بعد ذلك إلى البيانات الموجودة في التخزين ذي الحالة.
يحقق SQL Managed Instance تكرار المنطقة عن طريق وضع نسخ متماثلة من مثيل SQL المدار عبر مناطق توفر متعددة. للتخلص من نقطة فشل واحدة ، يتم أيضا تكرار حلقة التحكم عبر مناطق متعددة. يتم توجيه نسبة استخدام الشبكة لمستوى التحكم إلى موازن تحميل يتم نشره أيضا عبر مناطق التوفر. يتحكم Azure Traffic Manager في توجيه نسبة استخدام الشبكة من مستوى التحكم إلى موازن التحميل.
Requirements
دعم المنطقة: يدعم التكرار الאזורי لمثيل SQL المدار في مناطق محددة. لمزيد من المعلومات، راجع المناطق المدعومة.
تكرار تخزين النسخ الاحتياطي: لتمكين تكرار المناطق لمثيل SQL المدار الخاص بك، قم بتعيين تكرار التخزين الاحتياطي على ZRS أو تخزين احتياطي في المنطقة الجغرافية (GZRS).
Cost
عند تمكين تكرار المنطقة، هناك تكلفة إضافية لمثيل SQL المدار والنسخ الاحتياطية المتكررة في المنطقة. لمزيد من المعلومات، راجع الأسعار.
يمكنك توفير المال من خلال الالتزام باستخدام موارد الحوسبة بسعر مخفض لفترة من الوقت، والتي تتضمن مثيلات متكررة في المنطقة في طبقة خدمة Business Critical. لمزيد من المعلومات، راجع الحجوزات لمثيل SQL المدار.
تكوين دعم منطقة التوفر
يشرح هذا القسم كيفية تكوين دعم منطقة التوفر لمثيلات SQL المدارة:
تمكين تكرار المنطقة: لمعرفة كيفية تكوين تكرار المنطقة على المثيلات الجديدة والموجودة، راجع تكوين تكرار المنطقة.
جميع عمليات التحجيم لمثيل SQL المدار، بما في ذلك تمكين تكرار المنطقة، هي عمليات عبر الإنترنت وتتطلب الحد الأدنى من وقت التوقف عن العمل أو لا يتطلب أي وقت تعطل. لمزيد من المعلومات، راجع مدة عمليات الإدارة.
تعطيل التكرار في المنطقة: يمكنك تعطيل تكرار المنطقة باتباع نفس الخطوات لتمكين تكرار المنطقة. هذه العملية هي عملية عبر الإنترنت مشابهة لترقية هدف مستوى الخدمة العادية. في نهاية العملية، يتم ترحيل المثيل من البنية الأساسية الزائدة عن الحاجة في المنطقة إلى البنية الأساسية أحادية المنطقة.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عندما يتم تكوين مثيل SQL المدار ليكون زائدا عن الحاجة في المنطقة وتشغيل جميع مناطق التوفر:
توجيه حركة المرور بين المناطق: أثناء العمليات العادية، يتم توجيه الطلبات إلى العقدة التي تقوم بتشغيل طبقة حساب SQL Managed Instance.
النسخ المتماثل للبيانات بين المناطق: يتم تخزين ملفات قاعدة البيانات في Azure Storage باستخدام ZRS، المرفق بأي عقدة تحتوي حاليا على عملية SQL Database Engine النشطة.
عمليات الكتابة متزامنة ولا تعتبر مكتملة حتى يتم نسخ البيانات بنجاح عبر جميع مناطق التوفر. يضمن هذا النسخ المتماثل المتزامن تناسقا قويا وعدم فقدان البيانات أثناء فشل المنطقة. ومع ذلك ، قد يؤدي ذلك إلى زمن انتقال كتابة أعلى قليلا مقارنة بالتخزين المتكرر محليا.
توجيه حركة المرور بين المناطق: أثناء العمليات العادية، يتم توجيه الطلبات إلى النسخة المتماثلة الأساسية لمثيل SQL المدار.
النسخ المتماثل للبيانات بين المناطق: تقوم النسخة المتماثلة الأساسية بدفع التغييرات بشكل مستمر ومتتابع إلى النسخ المتماثلة الثانوية في مناطق التوفر المختلفة. تضمن هذه العملية استمرار البيانات على عدد كاف من النسخ المتماثلة الثانوية قبل تنفيذ كل حركة. توجد هذه النسخ المتماثلة في مناطق توفر مختلفة. تضمن هذه العملية أنه إذا أصبحت النسخة المتماثلة الأساسية أو النسخة المتماثلة الثانوية القابلة للقراءة غير متوفرة لأي سبب من الأسباب، فإن النسخة المتماثلة المتزامنة بالكامل متوفرة دائما لتجاوز الفشل.
نظرا لأن المثيلات الزائدة عن الحاجة في المنطقة تحتوي على نسخ متماثلة في مراكز بيانات مختلفة مع بعض المسافة بينها، فقد يؤدي زمن انتقال الشبكة المتزايد إلى زيادة وقت تنفيذ المعاملة. يمكن أن تؤثر هذه الزيادة على أداء بعض أحمال عمل معالجة المعاملات عبر الإنترنت (OLTP). معظم التطبيقات ليست حساسة لهذا الكمون الإضافي.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيل SQL المدار ليكون زائدا عن الحاجة في المنطقة وعدم توفر منطقة توفر واحدة أو أكثر:
- الكشف والاستجابة: SQL Managed Instance مسؤول عن اكتشاف فشل في منطقة توفر والاستجابة له. لا تحتاج إلى القيام بأي شيء لبدء تجاوز فشل المنطقة.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام Azure Service Health لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
- الطلبات النشطة: عندما تكون منطقة التوفر غير متوفرة، يتم إنهاء أي طلبات تتم معالجتها في منطقة التوفر المعيبة ويجب إعادة محاولتها. لجعل تطبيقاتك مقاومة لهذه الأنواع من المشكلات، راجع إرشادات الصمود ضد الأعطال المؤقتة .
إعادة توجيه حركة المرور: يعمل SQL Managed Instance مع Service Fabric لنقل محرك قاعدة البيانات إلى عقدة حساب مناسبة عديمة الحالة موجودة في منطقة توفر مختلفة ولديها سعة حرة كافية. بعد اكتمال تجاوز الفشل، تتم إعادة توجيه الاتصالات الجديدة تلقائيا إلى عقدة الحوسبة الأساسية الجديدة.
قد يواجه حمل العمل الثقيل بعض تدهور الأداء أثناء الانتقال من عقدة حساب إلى عقدة حساب أخرى لأن عملية محرك قاعدة البيانات الجديدة تبدأ بذاكرة تخزين مؤقت باردة.
- إعادة توجيه حركة المرور: يعمل SQL Managed Instance مع Service Fabric لتحديد نسخة متماثلة مناسبة في منطقة توفر أخرى لتصبح النسخة المتماثلة الأساسية. بعد أن تصبح النسخة المتماثلة الثانوية هي النسخة المتماثلة الأساسية الجديدة، يتم إنشاء نسخة متماثلة ثانوية أخرى للتأكد من أن نظام المجموعة يحتوي على عدد كاف من النسخ المتماثلة للحفاظ على النصاب القانوني. بعد اكتمال تجاوز الفشل، تتم إعادة توجيه الاتصالات الجديدة تلقائيا إلى النسخة المتماثلة الأساسية الجديدة، أو النسخة المتماثلة الثانوية القابلة للقراءة، استنادا إلى سلسلة الاتصال.
وقت التوقف المتوقع: قد يكون هناك قدر صغير من وقت التوقف عن العمل أثناء تجاوز فشل منطقة التوفر. عادة ما يكون وقت التوقف أقل من 30 ثانية، وهو ما يجب أن يتحمله تطبيقك إذا اتبع توجيهات Resilience to Fault المؤقتة .
فقدان البيانات المتوقع: لا يوجد فقدان بيانات متوقع للمعاملات الملتزمة أثناء تجاوز فشل منطقة التوفر. يجب إعادة المعاملات قيد الجريمة.
استعادة المنطقة
عند استرداد منطقة التوفر، يعمل SQL Managed Instance مع Service Fabric لاستعادة العمليات في المنطقة المستردة. لا يلزم تدخل العميل.
اختبار فشل المنطقة
يدير النظام الأساسي للمثيل المدار SQL توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الفشل للمثيلات المتكررة في المنطقة. نظرا لإدارة هذه الميزة بالكامل، لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها. ومع ذلك، يمكنك التحقق من صحة معالجة التطبيق الخاص بك مع حالات الفشل
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
يتم نشر مثيل SQL المدار الفردي داخل منطقة واحدة. ومع ذلك، يمكنك نشر مثيل SQL مدار ثانوي في منطقة Azure منفصلة وتكوين مجموعة تجاوز الفشل.
مجموعات الفشل
تقوم مجموعات تجاوز الفشل تلقائيا بنسخ بياناتك جغرافيا ويمكن أن تفشل تلقائيا أو يدويا في حالة حدوث فشل إقليمي، استنادا إلى نهج تجاوز الفشل.
يلخص هذا القسم المعلومات الأساسية حول مجموعات تجاوز الفشل، ولكن من المهم مراجعة نظرة عامة على مجموعات تجاوز الفشل وأفضل الممارسات لمعرفة المزيد حول كيفية عملها وكيفية تكوينها.
نهج تجاوز الفشل
عند إنشاء مجموعة تجاوز الفشل، يمكنك تحديد نهج تجاوز الفشل، الذي يحدد المسؤول عن اكتشاف انقطاع التيار الكهربائي وإجراء تجاوز الفشل. يمكنك تكوين نوعين من نهج تجاوز الفشل:
تجاوز الفشل المدار من قبل العميل (موصى به): عند استخدام نهج تجاوز الفشل المدار من قبل العميل، يمكنك تحديد ما إذا كنت تريد إجراء تجاوز الفشل، والذي لا يتسبب في فقدان البيانات، أو تجاوز الفشل القسري، مما قد يؤدي إلى فقدان البيانات. يتم استخدام تجاوز الفشل القسري كطريقة استرداد أثناء الانقطاعات عندما يتعذر الوصول إلى المثيل الأساسي.
تجاوز الفشل الذي تديره Microsoft: يتم استخدام تجاوز الفشل الذي تديره Microsoft فقط في حالات استثنائية لتشغيل تجاوز الفشل الإجباري.
Important
استخدم خيارات تجاوز الفشل التي يديرها العميل لتطوير خطط التعافي من الكوارث واختبارها وتنفيذها. لا تعتمد على تجاوز الفشل الذي تديره Microsoft، والذي قد يتم استخدامه فقط في الظروف القصوى. من المحتمل أن يتم بدء تجاوز الفشل الذي تديره Microsoft لمنطقة بأكملها. لا يمكن بدء تشغيله لمجموعات تجاوز الفشل الفردية أو مثيلات SQL المدارة أو الاشتراكات أو العملاء. قد يحدث تجاوز الفشل في أوقات مختلفة لخدمات Azure المختلفة. نوصي باستخدام تجاوز الفشل المدار من قبل العميل.
دعم المنطقة
يمكنك تحديد أي منطقة Azure لمثيلات SQL المدارة داخل مجموعة تجاوز الفشل. نظرا لزمن الوصول العالي لشبكات المنطقة الواسعة، يستخدم النسخ المتماثل الجغرافي آلية نسخ متماثل غير متزامنة. لتقليل تأخيرات الشبكة، حدد المناطق التي تحتوي على اتصالات زمن انتقال منخفض. لمزيد من المعلومات حول زمن الانتقال بين مناطق Azure، راجع إحصائيات زمن انتقال شبكة Azure ذهابا وإيابا.
Cost
عند إنشاء مثيلات SQL مدارة متعددة في مناطق مختلفة، تتم محاسبتك على كل مثيل مدار SQL.
ومع ذلك، إذا لم يكن المثيل الثانوي يحتوي على أي أحمال عمل أو تطبيقات للقراءة متصلة به، فيمكنك توفير تكاليف الترخيص عن طريق تعيين النسخة المتماثلة كمثيل احتياطي. لمزيد من المعلومات، راجع تكوين نسخة احتياطية بدون ترخيص لمثيل SQL المدار.
لمزيد من المعلومات حول تسعير SQL Managed Instance، راجع معلومات تسعير الخدمة.
تكوين الدعم متعدد المناطق
لمعرفة كيفية تكوين مجموعة تجاوز الفشل، راجع تكوين مجموعة تجاوز الفشل لمثيل SQL المدار.
تخطيط القدرات وإدارتها
أثناء تجاوز الفشل، تتم إعادة توجيه نسبة استخدام الشبكة إلى مثيل SQL مدار ثانوي. من المهم أن يكون مثيل SQL المدار الثانوي جاهزا لتلقي نسبة استخدام الشبكة. قم بإنشاء مثيل مدار SQL ثانوي بنفس مستوى الخدمة وإنشاء الأجهزة وحجم الحساب مثل المثيل الأساسي.
لمزيد من المعلومات حول تحجيم مثيلات SQL المدارة في مجموعة تجاوز الفشل، راجع قياس المثيلات.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات SQL المدارة لاستخدام مجموعات تجاوز الفشل متعددة المناطق وتشغيل جميع المناطق:
توجيه حركة المرور بين المناطق: أثناء العمليات العادية، تنتقل طلبات القراءة والكتابة إلى المثيل الأساسي الفردي في المنطقة الأساسية.
توفر مجموعات تجاوز الفشل أيضا نقطة نهاية مستمع منفصلة للقراءة فقط. أثناء العمليات العادية، تتصل نقطة النهاية هذه بالمثيل الثانوي لتوجيه نسبة استخدام الشبكة للقراءة فقط المحددة في سلسلة الاتصال.
لمزيد من المعلومات حول كيفية إرسال مجموعات تجاوز الفشل لحركة المرور إلى كل مثيل وكيف يمكنك توجيه نسبة استخدام الشبكة إلى نقطة نهاية مستمع للقراءة فقط، راجع نظرة عامة على مجموعات تجاوز الفشل وأفضل الممارسات.
النسخ المتماثل للبيانات بين المناطق: بشكل افتراضي، يتم نسخ البيانات بشكل غير متزامن من المثيل الأساسي إلى مثيل SQL الثانوي المدار.
نظرا لأن النسخ المتماثل الجغرافي غير متزامن، إذا قمت بإجراء تجاوز فشل إجباري، فمن الممكن أن تواجه فقدان البيانات. يمكنك مراقبة تأخر النسخ المتماثل لفهم فقدان البيانات المحتمل أثناء تجاوز الفشل القسري. لمزيد من المعلومات، راجع قائمة التحقق من التعافي من الكوارث.
إذا كنت بحاجة إلى التخلص من فقدان البيانات من النسخ المتماثل غير المتزامن أثناء تجاوز الفشل، فقم بتكوين التطبيق الخاص بك لحظر مؤشر ترابط الاستدعاء حتى يؤكد أن آخر معاملة تم الالتزام بها قد تم إرسالها وتقويتها في سجل المعاملات لقاعدة البيانات الثانوية. يتطلب هذا النهج تطويرا مخصصا ويقلل من أداء التطبيق الخاص بك. لمزيد من المعلومات، راجع منع فقدان البيانات الهامة.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات SQL المدارة لاستخدام مجموعات تجاوز الفشل متعددة المناطق وهناك انقطاع في المنطقة الأساسية:
الكشف والاستجابة: تعتمد مسؤولية الكشف والاستجابة على نهج تجاوز الفشل الذي تستخدمه مجموعة تجاوز الفشل.
نهج تجاوز الفشل المدار من قبل العميل: أنت مسؤول عن اكتشاف الفشل في منطقة ما وتشغيل تجاوز الفشل أو تجاوز الفشل القسري إلى المثيل الثانوي في مجموعة تجاوز الفشل.
إذا قمت بإجراء تجاوز الفشل، ينتظر SQL Managed Instance مزامنة البيانات مع المثيل الثانوي قبل تنفيذ إجراء تجاوز الفشل.
إذا قمت بإجراء تجاوز فشل إجباري، يقوم SQL Managed Instance على الفور بتبديل المثيل الثانوي إلى الدور الأساسي دون انتظار التغييرات الأخيرة للنشر من الأساسي. يمكن أن يؤدي هذا النوع من تجاوز الفشل إلى فقدان البيانات.
نهج تجاوز الفشل المدار من Microsoft: يتم إجراء عمليات تجاوز الفشل المدارة من Microsoft في ظل ظروف استثنائية. عندما تقوم Microsoft بتشغيل تجاوز الفشل، تقوم مجموعة تجاوز الفشل تلقائيا بإجراء تجاوز فشل إجباري على المثيل الثانوي في مجموعة تجاوز الفشل. ومع ذلك، نوصي باستخدام نهج تجاوز الفشل المدار من قبل العميل لأحمال عمل الإنتاج حتى تتمكن من التحكم في وقت حدوث تجاوز الفشل.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام Azure Service Health لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
الطلبات النشطة: عند حدوث تجاوز الفشل، يتم إنهاء أي طلبات تتم معالجتها ويجب إعادة محاولتها. لجعل تطبيقاتك مقاومة لهذه الأنواع من المشكلات، راجع مرونة الأخطاء المؤقتة.
فقدان البيانات المتوقع: يعتمد مقدار فقدان البيانات على كيفية تكوين التطبيق الخاص بك. لمزيد من المعلومات، راجع نظرة عامة على مجموعات تجاوز الفشل وأفضل الممارسات.
التوقف عن العمل المتوقع: قد يكون هناك قدر ضئيل من وقت التوقف أثناء تجاوز فشل مجموعة تجاوز الفشل. عادة ما يكون وقت التوقف أقل من 60 ثانية.
إعادة توجيه حركة المرور: بعد أن تكمل مجموعة تجاوز الفشل عملية تجاوز الفشل، يتم توجيه نسبة استخدام الشبكة للقراءة والكتابة إلى المثيل الأساسي الجديد تلقائيا. إذا كانت تطبيقاتك تستخدم نقاط نهاية مجموعة تجاوز الفشل في سلاسل الاتصال الخاصة بها، فلن تحتاج إلى تعديل سلاسل الاتصال الخاصة بها بعد تجاوز الفشل.
انتعاش المنطقة
لا تفشل مجموعات تجاوز الفشل تلقائيا في العودة إلى المنطقة الأساسية عند استعادتها، وبالتالي تقع على عاتقك مسؤولية بدء إرجاع الفشل.
اختبار حالات فشل المنطقة
يمكنك اختبار تجاوز الفشل لمجموعة تجاوز الفشل.
يعد اختبار مجموعة تجاوز الفشل جزءا واحدا فقط من إجراء تدريب DR. لمزيد من المعلومات، راجع إجراء تدريبات الإصلاح بعد كارثة (DR).
النسخ الاحتياطي والاستعادة
خذ نسخا احتياطية من قواعد البيانات الخاصة بك للحماية من المخاطر المختلفة ، بما في ذلك فقدان البيانات. يمكن استعادة النسخ الاحتياطية للتعافي من فقدان البيانات العرضي أو التلف أو غيرها من المشكلات. النسخ الاحتياطية ليست هي نفسها النسخة المتماثلة الجغرافية ، ولها أغراض مختلفة وتخفف من المخاطر المختلفة.
يأخذ SQL Managed Instance تلقائيا نسخا احتياطية كاملة وتفاضلية وسجل المعاملات لقواعد البيانات الخاصة بك. لمزيد من المعلومات حول أنواع النسخ الاحتياطية وتواترها وإمكانيات الاستعادة وتكاليف التخزين وتشفير النسخ الاحتياطي، راجع النسخ الاحتياطية التلقائية في مثيل SQL المدار.
يوفر SQL Managed Instance نسخا احتياطية تلقائية مضمنة ويدعم أيضا النسخ الاحتياطية للنسخ فقط التي يبدأها المستخدم لقواعد بيانات المستخدم. لمزيد من المعلومات، راجع النسخ الاحتياطية للنسخ فقط.
النسخ المتماثل للنسخ الاحتياطي
عند تكوين النسخ الاحتياطية التلقائية لمثيل SQL المدار الخاص بك، يمكنك تحديد كيفية النسخ المتماثل للنسخ الاحتياطية. تتمتع النسخ الاحتياطية التي تم تكوينها ليتم تخزينها على ZRS بمستوى أعلى من المرونة. نوصي بتكوين النسخ الاحتياطية لاستخدام أحد أنواع التخزين التالية:
ZRS للمرونة داخل المنطقة، إذا كانت المنطقة بها مناطق توفر
GZRS لتحسين مرونة النسخ الاحتياطية عبر المناطق إذا كانت المنطقة تحتوي على مناطق توفر وتم إقرانها بمنطقة أخرى
GRS إذا كانت منطقتك لا تتوافق مع مناطق توافر التوفر ولكن لديها منطقة مقترنة
لمزيد من المعلومات حول أنواع التخزين المختلفة وإمكانياتها، راجع تكرار تخزين النسخ الاحتياطي.
الاستعادة الجغرافية
تعد إمكانية الاستعادة الجغرافية حلا أساسيا للتعافي من الكوارث يسمح لك باستعادة النسخ الاحتياطية إلى منطقة Azure مختلفة. يتطلب النسخ الاحتياطي الجغرافي عادة قدرا كبيرا من وقت التوقف عن العمل وفقدان البيانات. لتحقيق مستويات أعلى من قابلية الاسترداد في حالة حدوث اضطراب إقليمي، يجب تكوين مجموعات تجاوز الفشل.
إذا كنت تستخدم الاستعادة الجغرافية، فأنت بحاجة إلى التفكير في كيفية إتاحة النسخ الاحتياطية في منطقتك الثانوية:
إذا تم إقران منطقتك الأساسية، فاستخدم تخزين النسخ الاحتياطي GZRS أو GRS لدعم الاستعادة الجغرافية للمنطقة المقترنة.
إذا لم يتم إقران منطقتك الأساسية، فيمكنك إنشاء حل مخصص لنسخ النسخ الاحتياطية إلى منطقة أخرى. ضع في اعتبارك استخدام النسخ الاحتياطية للنسخ فقط التي بدأها المستخدم وتخزينها في حساب تخزين يستخدم النسخ المتماثل لعنصر كائن ثنائي كبير الحجم للنسخ المتماثل إلى حساب تخزين في منطقة أخرى.
المرونة في صيانة الخدمة
عندما يقوم SQL Managed Instance بإجراء صيانة على المثيل الخاص بك، يظل مثيل SQL المدار متاحا بالكامل ولكن يمكن أن يخضع لعمليات إعادة تكوين قصيرة. قد تلاحظ تطبيقات العميل انقطاعات قصيرة في الاتصال عند حدوث حدث صيانة. يجب أن تتبع تطبيقات العميل إرشادات الصمود أمام الأعطال المؤقتة لتقليل التأثيرات.
يمكنك SQL Managed Instance من تحديد نافذة صيانة تستخدم بشكل عام لترقيات الخدمة وعمليات الصيانة الأخرى. يمكن أن يساعدك تكوين نافذة الصيانة في تقليل أي آثار جانبية، مثل تجاوز الأعطال التلقائي، خلال ساعات العمل. يمكنك أيضا تلقي إشعار مسبق بالصيانة المخطط لها.
لمزيد من المعلومات، راجع نافذة الصيانة في SQL Managed Instance.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
بالنسبة إلى SQL Managed Instance، لا تنطبق اتفاقية مستوى الخدمة للتوفر إلا عندما يتم تكوين شبكة Azure الظاهرية بشكل صحيح بحيث لا تعيق نسبة استخدام الشبكة للإدارة. يتضمن هذا التكوين حجم الشبكة الفرعية ومجموعات أمان الشبكة (NSGs) والمسارات المعرفة من قبل المستخدم (UDRs) وتكوين DNS والموارد الأخرى التي تؤثر على إدارة موارد الشبكة واستخدامها. لمزيد من المعلومات حول تكوين الشبكة المطلوب لمثيل SQL المدار، راجع متطلبات الشبكة.