مشاركة عبر

تجاوز الفشل اليدوي الذي بدأه المستخدم على SQL المُدار من المثيل

  • مقالة

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

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

ملاحظة

لا تتعلق هذه المقالة بعمليات تجاوز الفشل عبر المناطق في مجموعات تجاوز الفشل التلقائي.

متى يجب استخدام تجاوز الفشل اليدوي

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

قد تفكر في تنفيذ تجاوز فشل يدوي على SQL Managed Instance لبعض الأسباب التالية:

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

ملاحظة

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

بدء تجاوز الفشل اليدوي في SQL Managed Instance

أذونات Azure RBAC مطلوبة

سيحتاج المستخدم الذي يبدأ تجاوز الفشل إلى أن يكون لديه أحد أدوار Azure التالية:

  • دور مالك الاشتراك، أو
  • Managed Instance Contributor أو
  • دور مخصص بالإذن التالي:
    • Microsoft.Sql/managedInstances/failover/action

استخدام PowerShell

يجب أن يكون الحد الأدنى من إصدار Az.Sql هو v2.9.0. ضع في اعتبارك استخدام Azure Cloud Shell من مدخل Microsoft Azure التي تحتوي دائماً على أحدث إصدار متوفر من PowerShell.

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

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

استخدم أمر PowerShell Invoke-AzSqlInstanceFailover مع المثال التالي لبدء تجاوز فشل العقدة الأساسية، التي تنطبق على كل من طبقة خدمة BC وGP.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

استخدم أمر PS التالي لتجاوز الفشل لقراءة العقدة الثانوية، التي تنطبق على طبقة خدمة BC فقط.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

باستخدام CLI

تأكد من تثبيت أحدث نصوص CLI النصية.

استخدم الأمر az sql mi فشل تجاوز CLI مع المثال التالي لبدء تجاوز فشل العقدة الأساسية، التي تنطبق على كل من طبقة خدمة BC وGP.

az sql mi failover -g myresourcegroup -n myinstancename

استخدم أمر CLI التالي لتجاوز الفشل لقراءة العقدة الثانوية، التي تنطبق على طبقة خدمة BC فقط.

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

استخدام واجهة برمجة تطبيقات REST

بالنسبة للمستخدمين المتقدمين الذين قد يحتاجون إلى التنفيذ التلقائي لعمليات فشل مثيلات SQL المُدارة الخاصة بهم لأغراض تنفيذ خط أنابيب الاختبار المستمر، أو أدوات تخفيف الأداء الآلي، يمكن إنجاز هذه الوظيفة من خلال بدء تجاوز الفشل من خلال استدعاء واجهة برمجة التطبيقات. راجع المثيلات المُدارة - واجهة برمجة تطبيقات REST لتجاوز الفشل للحصول على التفاصيل.

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

التعليمة البرمجية الآتية هو مثال على API URI للاتصال:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

يجب تمرير الخصائص الآتية في استدعاء API:

خاصية واجهة برمجة التطبيقات المعلمة
subscriptionId معرف الاشتراك الذي تم نشر مثيل مُدار عليه
ResourceGroupName مجموعة الموارد التي تحتوي على مثيل مُدار
managedInstanceName اسم المثيل المُدار
نوع النسخة المتماثلة (اختياري) (أساسي أو ثانوي قابل للقراءة). تمثل هذه المعلمات نوع النسخة المتماثلة التي سيتم إخفاقها: أساسية أو ثانوية قابلة للقراءة. إذا لم يتم تحديده، فسيتم بدء تجاوز الفشل على النسخة المتماثلة الأساسية بشكل افتراضي.
api-version قيمة ثابتة ويجب حالياً أن تكون "2019-06-01-preview"

ستكون استجابة واجهة برمجة التطبيقات واحدة ما يلي:

  • 202 مقبولة
  • أحد أخطاء الطلبات 400.

يمكن تتبع حالة العملية من خلال مراجعة استجابات واجهة برمجة التطبيقات في رؤوس الاستجابة. لمزيد من المعلومات، راجع حالة عمليات Azure غير المتزامنة.

راقب تجاوز الفشل

لمراقبة تقدم المستخدم في تجاوز الفشل لمثيل BC الخاص بك، نفِّذ استعلام T-SQL الآتي في عميلك المفضل (مثل SSMS) في مثيل مُدار من SQL. سيقرأ عرض النظام sys.dm_hadr_fabric_replica_states وتقرير النسخ المتماثلة المتاحة في المثيل. حدِّث نفس الاستعلام بعد بدء تجاوز الفشل اليدوي.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

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

لن تتمكن من رؤية نفس الإخراج مع طبقة خدمة GP كما هو موضح أعلاه لـ BC. وذلك لأن طبقة خدمة GP تعتمد على عقدة واحدة فقط. يمكنك استخدام استعلام T-SQL بديل يوضح الوقت الذي بدأت فيه عملية SQL على العقدة لمثيل طبقة خدمة GP:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

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

ملاحظة

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

هام

القيود الوظيفية لتجاوز الفشل اليدوي التي يبدأها المستخدم هي:

  • قد يتم بدء تجاوز فشل واحد (1) على نفس المثيل المُدار كل 15 دقيقة.
  • بالنسبة لنسخ BC، يجب أن يكون هناك نصاب من النسخ المتماثلة حتى يتم قبول طلب تجاوز الفشل.
  • بالنسبة لمثيلات BC، لا يمكن تحديد النسخة المتماثلة الثانوية القابلة للقراءة لبدء تجاوز الفشل عليها.
  • لن يُسمح بتجاوز الفشل حتى تكتمل النسخ الاحتياطية الكاملة الأولى لقاعدة بيانات جديدة بواسطة أنظمة النسخ الاحتياطي الآلية.
  • لن يتم السماح بتجاوز الفشل في حالة وجود استعادة قاعدة بيانات قيد التقدم.

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