إمكانية وصول عالية إلى Azure SQL Database وSQL Managed Instance

  • مقالة

ينطبق على: قاعدة بيانات Azure SQL مثيل Azure SQL المُدار

يكمن الهدف من البنية عالية التوافر في Azure SQL Database وSQL Managed Instance في ضمان تشغيل قاعدة بياناتك وتشغيلها بحد أدنى 99.99٪ من الوقت دون القلق بشأن تأثير عمليات الصيانة وانقطاع التيار. لمزيد من المعلومات عن اتفاقية مستوى الخدمة المحددة (SLA) لطبقات مختلفة، راجع SLA لـAzure SQL Database وSLA لـAzure SQL Managed Instance.

يتعامل Azure تلقائياً مع مهام الخدمة الحرجة، مثل التحديث الجزئي، والنسخ الاحتياطية، وترقيات Windows وAzure SQL، والأحداث غير المخطط لها مثل فشل الأجهزة الأساسية أو البرامج أو الشبكة. عندما يتم تصحيح قاعدة البيانات الأساسية في Azure SQL Database أو فشلها، لا يمكن ملاحظة وقت التوقف إذا استخدمت منطق إعادة المحاولة في تطبيقك. يمكن لـ SQL Database وSQL Managed Instance الاسترداد بسرعة حتى في أكثر الظروف خطورة لضمان توفر بياناتك دائماً.

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

هناك نوعان من النماذج المعمارية عالية التوافر:

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

يتم تشغيل كل من SQL Database وSQL Managed Instance على أحدث إصدار ثابت من محرك قاعدة بيانات SQL Server ونظام التشغيل Windows، ولن يلاحظ معظم المستخدمين إجراء الترقيات بشكل مستمر.

توفر طبقة خدمة أساسية وقياسية وعامة للأغراض العامة توفر فائض عن الحاجة محلياً

تستخدم مستويات الخدمة Basic وStandard وGeneral Purpose بنية الإتاحة القياسية لكل من الحوسبة بلا خادم والحوسبة المزودة. يوضح الشكل التالي أربع عقد مختلفة مع طبقات الحوسبة والتخزين المنفصلة.

Separation of compute and storage

يشتمل نموذج التوافر القياسي على طبقتين:

  • طبقة حساب عديمة الحالة تقوم بتشغيل عملية sqlservr.exe وتحتوي فقط على بيانات مؤقتة ومخزنة مؤقتاً، مثل TempDB وقواعد بيانات النموذج على SSD المرفق وذاكرة التخزين المؤقت للخطة وتجمع المخزن المؤقت وكذلك تجمع مخزن الأعمدة في الذاكرة. يتم تشغيل هذه العقدة عديمة الحالة بواسطة Azure Service Fabric الذي يهيئ sqlservr.exe ويتحكم في صحة العقدة وينفذ تجاوز الفشل لعقدة أخرى إذا لزم الأمر.
  • طبقة بيانات ذات حالة تحتوي على ملفات قاعدة البيانات (.mdf/.ldf) المخزنة في Azure Blob storage. يحتوي تخزين Azure Blob على ميزة توفر البيانات والتكرار المضمنة. فهو يضمن إمكانية الاحتفاظ بكل سجل في ملف السجل أو صفحة في ملف البيانات حتى في حالة تعطل العملية sqlservr.exe.

عندما تتم ترقية محرك قاعدة البيانات أو نظام التشغيل أو اكتشاف فشل، فإن Azure Service Fabric سينقل العملية عديمة الحالة sqlservr.exe إلى عقدة حساب أخرى عديمة الحالة ذات سعة حرة كافية. لا تتأثر البيانات في تخزين Azure Blob بالنقل، ويتم إرفاق ملفات البيانات/السجل بعملية sqlservr.exe التي تمت تهيئتها حديثاً. تضمن هذه العملية توفراً بنسبة 99.99٪، ولكن قد يتعرض عبء العمل الثقيل لبعض التدهور في الأداء أثناء عملية الانتقال نظراً لأن عملية sqlservr.exe الجديدة تبدأ بذاكرة التخزين المؤقت الباردة.

توفير منطقة طبقة خدمة زائدة عن الحاجة لـGeneral Purpose

يتم تقديم تكوين المنطقة الزائدة عن الحاجة لطبقة خدمة الأغراض العامة لكل من الحوسبة بلا خادم والحوسبة المزودة. يستخدم هذا التكوين Azure Availability Zones لنسخ قواعد البيانات عبر مواقع فعلية متعددة داخل منطقة Azure. من خلال تحديد التكرار في المنطقة، يمكنك جعل قواعد بياناتك الفردية الجديدة والحالية بلا خادم والمزودة بأغراض عامة والمجموعات المرنة لمجموعة أكبر من حالات الفشل، بما في ذلك حالات انقطاع مراكز البيانات الكارثية، دون أي تغييرات في القواعد المنطقية للبرنامج.

يتكون تكوين المنطقة الزائدة عن الحاجة لطبقة الأغراض العامة من طبقتين:

  • طبقة بيانات ذات حالة تحتوي على ملفات قاعدة البيانات (.mdf/.ldf) المخزنة في ZRS (تخزين المنطقة المكرر). باستخدام ZRS، يتم نسخ ملفات البيانات والسجلات بشكل متزامن عبر ثلاث مناطق توفر Azure معزولة مادياً.
  • طبقة حساب عديمة الحالة تقوم بتشغيل عملية sqlservr.exe وتحتوي فقط على بيانات عابرة ومخزنة مؤقتاً، مثل TempDB، وقواعد بيانات النموذج على SSD المرفق، وذاكرة التخزين المؤقت للخطة، وتجمع المخزن المؤقت، وتجمع مخزن الأعمدة في الذاكرة. يتم تشغيل هذه العقدة عديمة الحالة بواسطة Azure Service Fabric الذي يهيئ sqlservr.exe ويتحكم في صحة العقدة وينفذ تجاوز الفشل لعقدة أخرى إذا لزم الأمر. بالنسبة لقواعد بيانات الأغراض العامة بلا خادم والمتوفرة في المنطقة، فإن العقد ذات السعة الاحتياطية متاحة بسهولة في Availability Zones الأخرى لتجاوز الفشل.

يوضح الرسم التخطيطي التالي إصدار المنطقة الزائدة عن الحاجة لبنية التوافر العالي لطبقة خدمة الأغراض العامة:

Zone redundant configuration for general purpose

هام

بالنسبة لطبقة الأغراض العامة، يتوفر تكوين المنطقة الزائدة عن الحاجة بشكل عام في المناطق التالية: غرب أوروبا، وشمال أوروبا، ومنطقة غرب الولايات المتحدة 2، وفرنسا الوسطى. هذا قيد الإصدار الأولي في المناطق التالية: شرق الولايات المتحدة، وشرق الولايات المتحدة 2، وجنوب شرق آسيا، وشرق أستراليا، وشرق اليابان، وجنوب المملكة المتحدة.

ملاحظة

لا يتوفر تكوين المنطقة الزائدة عن الحاجة في SQL Managed Instance. في قاعدة بيانات SQL، لا تتوفر هذه الميزة إلا عند تحديد جهاز Gen5.

توفر مستويات الخدمة "المتميزة" و"الأعمال المهمة" فئة خدمة متكررة محلياً

تستخدم مستويات الخدمة Premium وBusiness Critical نموذج التوفر المميز، الذي يدمج موارد الحوسبة (sqlservr.exe العملية) والتخزين (SSD المرفق محلياً) على عقدة واحدة. يتم تحقيق الإتاحة العالية من خلال نسخ متماثلة لكل من الحوسبة والتخزين إلى عقد إضافية ما يؤدي إلى إنشاء مجموعة مكونة من ثلاث إلى أربع عقد.

Cluster of database engine nodes

يتم وضع ملفات قاعدة البيانات الأساسية (.mdf/.ldf) على وحدة تخزين SSD المرفقة لتوفير زمن انتقال منخفض جداً لعمليات الإدخال والإخراج لحمل العمل لديك. تُنفذ الإتاحة العالية باستخدام تقنية مشابهة لـ Microsoft SQL Server مجموعات قابلية وصول عالية التوفر AlwaysOn. تتضمن المجموعة نسخة متماثلة أساسية واحدة يمكن الوصول إليها لأحمال عمل العميل للقراءة والكتابة، وما يصل إلى ثلاث نسخ متماثلة ثانوية (حساب وتخزين) تحتوي على نسخ من البيانات. تدفع العقدة الأساسية باستمرار التغييرات إلى العقد الثانوية بالترتيب وتضمن استمرار البيانات في نسخة مماثلة ثانوية واحدة على الأقل قبل تثبيت كل عملية. تضمن هذه العملية أنه إذا تعطلت العقدة الأساسية لأي سبب من الأسباب، فهناك دائماً عقدة متزامنة بالكامل تفشل فيها. يتم بدء تجاوز الفشل بواسطة Azure Service Fabric. بمجرد أن تصبح النسخة المتماثلة الثانوية هي العقدة الأساسية الجديدة، يتم إنشاء نسخة متماثلة ثانوية أخرى لضمان احتواء الكتلة على عدد كافٍ من العقد (مجموعة الحصص). بمجرد اكتمال تجاوز الفشل، تتم إعادة توجيه اتصالات Azure SQL تلقائياً إلى العقدة الأساسية الجديدة.

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

توفر مستويات الخدمة "المتميزة" و"الأعمال المهمة" فئة خدمة متكررة محلياً

بشكل افتراضي، يتم إنشاء مجموعة العقد الخاصة بنموذج التوفر المتميز في نفس مركز البيانات. من خلال تقديم مناطق توافر Azure، يمكن لـ SQL Database وضع نسخ متماثلة مختلفة من قاعدة بيانات الأعمال المهمة إلى مناطق توافر مختلفة في نفس المنطقة. للتخلص من نقطة فشل واحدة، يتم أيضاً تكرار حلقة التحكم عبر مناطق متعددة على شكل ثلاث حلقات بوابة (GW). يتم التحكم في التوجيه إلى حلقة عبارة معينة بواسطة Azure Traffic Manager (ATM). نظراً لأن تكوين المنطقة الزائدة عن الحاجة في طبقات الخدمة Premium أو Business Critical لا يُنشئ تكراراً إضافياً لقاعدة البيانات، يمكنك تمكينه دون تكلفة إضافية. من خلال تحديد تكوين المنطقة الزائدة عن الحاجة، يمكنك جعل قواعد بيانات Premium أو Business Critical مرنة في مواجهة مجموعة أكبر من حالات الفشل، بما في ذلك الانقطاعات الكارثية لمراكز البيانات، دون أي تغييرات في القواعد المنطقية للبرنامج. يمكنك أيضاً تحويل أي قواعد بيانات أو مجموعات بيانات Premium أو Business Critical موجودة إلى تكوين المنطقة الزائدة عن الحاجة.

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

هام

وهذه الميزة غير متوفرة في SQL Managed Instance. في قاعدة بيانات SQL، عند استخدام الطبقة Business Critical، لا يتوفر تكوين المنطقة الزائدة عن الحاجة إلا عند تحديد جهاز Gen5. للحصول على معلومات محدثة عن المناطق التي تدعم قواعد بيانات المنطقة الزائدة عن الحاجة، راجع دعم الخدمات حسب المنطقة.

يتم توضيح إصدار المنطقة الزائدة عن الحاجة لبنية قابلية وصول العالية من خلال الرسم التخطيطي التالي:

high availability architecture zone redundant

طبقة الخدمة الفائقة المتوفرة محلياً

يتم وصف بنية مستوى الخدمة الفائقة في هندسة الدالات الموزعة وهي متوفرة حاليا فقط لـ SQL Database، وليس SQL Managed Instance.

Hyperscale functional architecture

يتضمن نموذج التوفر في المقياس الفائق أربع طبقات:

  • طبقة حساب عديمة الحالة تقوم بتشغيل عملية sqlservr.exe وتحتوي فقط على بيانات عابرة ومخزنة مؤقتاً، مثل ذاكرة التخزين المؤقت RBPEX، وقواعد بيانات النموذج على SSD المرفق، وذاكرة التخزين المؤقت للخطة، وتجمع المخزن المؤقت، وتجمع مخزن الأعمدة في الذاكرة. تتضمن هذه الطبقة عديمة الحالة النسخة المتماثلة الأساسية للحوسبة واختيارياً عدداً من النسخ المتماثلة الثانوية للحوسبة التي يمكن أن تكون بمثابة أهداف تجاوز الفشل.
  • طبقة تخزين عديمة الحالة تم تشكيلها بواسطة خوادم الصفحات. هذه الطبقة هي مشغل التخزين الموزع sqlservr.exe للعمليات التي تعمل على النسخ المتماثلة للحساب. يحتوي كل خادم صفحة على بيانات عابرة ومخزنة مؤقتاً، مثل تغطية ذاكرة التخزين المؤقت RBPEX على SSD المرفق، وصفحات البيانات المخزنة مؤقتا في الذاكرة. يحتوي كل خادم صفحة على خادم صفحات مقترن بتكوين نشط لتوفير موازنة التحميل والتكرار والتوفر العالي.
  • طبقة تخزين سجل العمليات ذات الحالة المتكونة من عقدة الحساب التي تشغل عملية خدمة السجل، ومنطقة هبوط سجل العمليات، وتخزين سجل العمليات طويل الأجل. تستخدم منطقة الهبوط والتخزين طويل الأجل Azure Storage، الذي يوفر التوافر والتكرار لسجل العمليات، ما يسمح يضمن استمرارية البيانات للعمليات المثبتة.
  • طبقة تخزين بيانات حالة مع ملفات قاعدة البيانات (.mdf/.ndf) المخزنة في Azure Storage ويتم تحديثها بواسطة خوادم الصفحات. تستخدم هذه الطبقة ميزات توفر البيانات والتكرار في Azure Storage. فهو يضمن أنه سيتم الاحتفاظ بكل صفحة في ملف البيانات حتى في حالة تعطل العمليات في طبقات أخرى من بنية المقياس الفائق أو في حالة فشل حساب العقد.

يتم تشغيل حساب العقد في جميع الطبقات الفائقة على Azure Service Fabric، الذي يتحكم في صحة كل عقدة وينفذ عمليات تجاوز الفشل للعقد الصحية المتاحة حسب الضرورة.

لمزيدٍ من المعلومات حول التوفر العالي في المقياس الفائق، راجع توفر عالي لقاعدة البيانات في المقياس الفائق.

التوفر الزائد عن الحاجة لمنطقة طبقة الخدمة Hyperscale (إصدار أولي)

التكرار في المنطقة لطبقة الخدمة Hyperscale Azure SQL Database هو الآن في الإصدار الأولي العام. يضمن تمكين هذا التكوين مرونة على مستوى المنطقة من خلال النسخ المماثل عبر Availability Zones لجميع طبقات Hyperscale. من خلال تحديد التكرار في المنطقة، يمكنك جعل قواعد بيانات Hyperscale الخاصة بك مرنة لمجموعة أكبر من الإخفاقات، بما في ذلك الانقطاعات الكارثية لمراكز البيانات، دون أي تغييرات في القواعد المنطقية للبرنامج.

خذ بعين الاعتبار القيود التالية:

  • حالياً، يتم دعم مناطق Azure التالية فقط: جنوب المملكة المتحدة وجنوب البرازيل ومنطقة غرب الولايات المتحدة الأمريكية 2 وشرق اليابان وشمال أوروبا وجنوب شرق آسيا ومنطقة وسط كندا ومنطقة وسط الولايات المتحدة الأمريكية وجنوب وسط الولايات المتحدة الأمريكية ووسط فرنسا وشرق أستراليا وغرب وسط ألمانيا وشرق آسيا ووسط كوريا وشرق النرويج وغرب الولايات المتحدة الأمريكية 3.
  • لا يمكن تحديد التكوين المكرر للمنطقة إلا أثناء إنشاء قاعدة البيانات. لا يمكن تعديل هذا الإعداد بمجرد توفير المورد. استخدم نسخة قاعدة البيانات، أو استرداد في نقطة زمنية، أو أنشئ نسخة جغرافية متماثلة لتحديث تكوين المنطقة المكررة لقاعدة بيانات Hyperscale موجودة. عند استخدام أحد هذه الخيارات للتحديث، إذا كانت قاعدة البيانات الهدف في منطقة مختلفة عن المصدر أو إذا كان تكرار تخزين النسخ الاحتياطي لقاعدة البيانات من الهدف يختلف عن قاعدة البيانات المصدر، فإن عملية النسخ ستكون بحجم عملية البيانات. بالإضافة إلى ذلك، عند استخدام أحد خيارات التحديث هذه، لن تحتوي قاعدة البيانات المستهدفة على بيانات النسخ الاحتياطي السابقة من قاعدة البيانات المصدر للاسترداد في نقطة زمنية.
  • النسخ المماثلة المسماة غير مدعومة.
  • يتم دعم نسخ احتياطي مكرر للمنطقة فقط.
  • يتم دعم أجهزة Gen5 فقط.
  • Geo-Restore غير مدعوم حالياً.
  • لا يمكن تحديد التكرار في المنطقة حالياً عند ترحيل قاعدة بيانات موجودة من طبقة خدمة Azure SQL Database أخرى إلى Hyperscale.

هام

يلزم وجود نسخة مماثلة واحدة ذات قابلية وصول عالية على الأقل واستخدام مخزن النسخ الاحتياطي في المنطقة لتمكين تكوين المنطقة الاحتياطية لـHyperscale.

إنشاء منطقة قاعدة بيانات Hyperscale زائدة عن الحاجة

استخدم Azure PowerShell أو Azure CLI لإنشاء منطقة قاعدة بيانات Hyperscale زائدة عن الحاجة. تأكد من أن لديك أحدث إصدار من API لضمان دعم أي تغييرات حديثة.

حدد المعلمة -ZoneRedundant لتمكين تكرار المنطقة لقاعدة بيانات Hyperscale باستخدام Azure PowerShell. يجب أن تحتوي قاعدة البيانات على نسخة مماثلة واحدة ذات قابلية وصول عالية على الأقل ويجب تحديد منطقة تخزين النسخ الاحتياطي الزائدة عن الحاجة.

لتمكين التكرار في المنطقة باستخدام Azure Powershell، استخدم المثال التالي للأمر:

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone

إنشاء قاعدة بيانات Hyperscale زائدة عن الحاجة في المنطقة عن طريق إنشاء نسخة مماثلة جغرافية

لجعل منطقة قاعدة بيانات Hyperscale حالية زائدة عن الحاجة، استخدم Azure PowerShell أو Azure CLI لإنشاء قاعدة بيانات Hyperscale زائدة عن الحاجة للمنطقة باستخدام النسخ المماثل الجغرافي النشط. يمكن أن تكون النسخة المماثلة الجغرافية في نفس المنطقة أو منطقة مختلفة مثل قاعدة بيانات Hyperscale الحالية.

حدد المعلمة -ZoneRedundant لتمكين تكرار المنطقة لقاعدة بيانات Hyperscale الثانوية. يجب أن تحتوي قاعدة البيانات الثانوية على نسخة مماثلة واحدة ذات قابلية وصول عالية على الأقل ويجب تحديد مساحة تخزين النسخ الاحتياطي للمنطقة الزائدة عن الحاجة.

لإنشاء قاعدة بيانات المنطقة المكررة باستخدام Azure PowerShell، استخدم المثال التالي للأمر:

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

إنشاء قاعدة بيانات Hyperscale مكررة في المنطقة عن طريق إنشاء نسخة من قاعدة البيانات

لجعل منطقة قاعدة بيانات Hyperscale حالية مكررة، استخدم Azure PowerShell أو Azure CLI لإنشاء قاعدة بيانات Hyperscale مكررة في المنطقة باستخدام نسخة من قاعدة البيانات. يمكن أن تكون نسخة قاعدة البيانات في نفس المنطقة أو في منطقة مختلفة مثل قاعدة بيانات Hyperscale الحالية.

حدد المعلمة -ZoneRedundant لتمكين تكرار المنطقة لنسخة من قاعدة بيانات Hyperscale. يجب أن تحتوي نسخة قاعدة البيانات على نسخة مماثلة واحدة ذات قابلية وصول عالية على الأقل ويجب تحديد منطقة تخزين النسخ الاحتياطي المكررة في المنطقة.

لإنشاء قاعدة بيانات المنطقة المكررة باستخدام Azure PowerShell، استخدم المثال التالي للأمر:

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone

استرداد قاعدة البيانات المتسارع (ADR)

Accelerated Database Recovery (ADR) هي ميزة جديدة لمحرك قاعدة البيانات تعمل على تحسين توفر قاعدة البيانات بشكل كبير، خاصة في حالة وجود عمليات طويلة الأمد. يتوفر ADR لـ Azure SQL Database وAzure SQL Managed Instance وAzure Synapse Analytics.

اختبار مرونة خطأ التطبيق

تعد قابلية الوصول العالية جزءاً أساسيّاً من نظام SQL Database وSQL Managed Instance الذي يعمل بشفافية مع تطبيقات قاعدة البيانات الخاصة بك. ومع ذلك، نحن ندرك أنك قد ترغب في اختبار كيفية تأثير عمليات تجاوز الفشل التلقائية التي بدأت أثناء الأحداث المخطط لها أو غير المخطط لها على التطبيق قبل نشره في الإنتاج. يمكنك تشغيل تجاوز الفشل يدوياً عن طريق استدعاء واجهة برمجة تطبيقات خاصة لإعادة تشغيل قاعدة بيانات أو تجمع مرن أو مثيل مدار. في حالة وجود قاعدة بيانات General Purpose أو تجمع مرن بلا خادم أو مزود بقاعدة بيانات زائدة عن الحاجة، قد ينتج عن استدعاء API إعادة توجيه اتصالات العميل إلى الأساسي الجديد في Availability Zone مختلفة عن Availability Zone الخدمات الخاصة بالأساسي القديم. لذلك، بالإضافة إلى اختبار كيفية تأثير تجاوز الفشل على جلسات عمل قاعدة البيانات الحالية، يمكنك أيضاً التحقق مما إذا كان سيغير الأداء الشامل بسبب التغييرات في زمن انتقال الشبكة. نظرا لأن عملية إعادة التشغيل تدخلية ويمكن لعدد كبير منهم الضغط على النظام الأساسي، يُسمح باستدعاء واحد فقط لتجاوز الفشل كل 15 دقيقة لكل قاعدة بيانات أو تجمع مرن أو مثيل مُدار.

يمكن بدء تجاوز الفشل باستخدام PowerShell أو REST API أو Azure CLI:

نوع التوزيع PowerShell REST API Azure CLI
قاعدة البيانات Invoke-AzSqlDatabaseFailover تجاوز فشل قاعدة البيانات يمكن استخدام az rest لاستدعاء REST API من Azure CLI
مجموعة مرنة Invoke-AzSqlElasticPoolFailover تجاوز فشل التجمع المرن يمكن استخدام az rest لاستدعاء REST API من Azure CLI
المثيل المدار Invoke-AzSqlInstanceFailover المثيلات المدارة - تجاوز الفشل يمكن استخدام تجاوز فشل az sql mi لاستدعاء استدعاء REST API من Azure CLI

هام

لا يتوفر الأمر تجاوز الفشل للنسخ المتماثلة الثانوية القابلة للقراءة لقواعد البيانات فائقة القياس.

الختام

تتميز Azure SQL Database وAzure SQL Managed Instance بحل توفر عالي مدمج ومتكامل بشكل عميق مع النظام الأساسي Azure. وهو يعتمد على "نسيج الخدمة" للكشف عن الفشل واسترداده، وعلى تخزين Azure Blob لحماية البيانات، وعلى مناطق التوفر لتحمل أخطاء أعلى (كما ذكر سابقاً في المستند غير القابل للتطبيق على Azure SQL Managed Instance حتى الآن). بالإضافة إلى ذلك، يستخدم SQL Database وSQL Managed Instance تقنية مجموعة Always On المتوفرة من مثيل SQL Server للنسخ المماثل وتجاوز الفشل. يتيح الجمع بين هذه التقنيات للتطبيقات تحقيق فوائد نموذج التخزين المختلط بالكامل ودعم اتفاقيات مستوى الخدمة الأكثر تطلباً.

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