قابلية الوصول العالية (الموثوقية) في Azure Cosmos DB ل NoSQL
توضح هذه المقالة دعم قابلية الوصول العالية (الموثوقية) في Azure CosmosDB ل NoSQL وتغطي كل من مناطق التوفر، بالإضافة إلى التعافي من الكوارث عبر المناطق واستمرارية الأعمال.
للحصول على توصيات المرونة العامة ل Azure Cosmos DB ل NoSQL، راجع توصيات المرونة ل Azure Cosmos DB ل NoSQL.
دعم منطقة القابلية للوصول
مناطق توفر Azure هي ثلاث مجموعات منفصلة فعليا على الأقل من مراكز البيانات داخل كل منطقة Azure. مراكز البيانات داخل كل منطقة مجهزة ببنية أساسية مستقلة للطاقة والتبريد والشبكات. في حالة فشل المنطقة المحلية، يتم تصميم مناطق التوفر بحيث إذا تأثرت المنطقة الواحدة، فإن الخدمات الإقليمية والسعة والتوافر العالي تدعمها المنطقتين المتبقيتين.
يمكن أن تتراوح حالات الفشل من فشل البرامج والأجهزة إلى الأحداث مثل الزلازل والفيضانات والحرائق. يتم تحقيق التسامح مع الفشل مع التكرار والعزلة المنطقية لخدمات Azure. لمزيد من المعلومات التفصيلية حول مناطق التوفر في Azure، راجع المناطق ومناطق التوفر.
تم تصميم الخدمات الممكنة لمناطق توفر Azure لتوفير المستوى الصحيح من الموثوقية والمرونة. يمكن تكوينها بطريقتين. يمكن أن تكون إما زائدة عن الحاجة للمنطقة، مع النسخ المتماثل التلقائي عبر المناطق، أو منطقة، مع تثبيت المثيلات في منطقة معينة. يمكنك أيضا الجمع بين هذه الأساليب. لمزيد من المعلومات حول البنية المناطقية مقابل البنية الزائدة عن الحاجة للمنطقة، راجع التوصيات لاستخدام مناطق التوفر والمناطق.
Azure Cosmos DB هي خدمة متعددة المستأجرين تدير جميع تفاصيل عقد الحوسبة الفردية بشفافية. لا داعي للقلق بشأن أي نوع من التصحيح أو الصيانة المخطط لها. يضمن Azure Cosmos DB اتفاقيات مستوى الخدمة للتوفر وزمن انتقال P99 من خلال جميع عمليات الصيانة التلقائية التي ينفذها النظام.
يقدم Azure Cosmos DB:
مرونة انقطاع العقدة الفردية. يقوم Azure Cosmos DB تلقائيا بتخفيف انقطاع النسخ المتماثلة عن طريق ضمان ثلاث نسخ متماثلة على الأقل من بياناتك في كل منطقة Azure لحسابك ضمن حصة مكونة من أربع نسخ متماثلة. ينتج عن هذا الضمان RTO من 0 وRPO من 0 انقطاع العقدة الفردية، دون الحاجة إلى تغييرات التطبيق أو التكوينات.
مرونة انقطاع المنطقة. عند نشر حساب Azure Cosmos DB باستخدام مناطق التوفر، يوفر Azure Cosmos DB RTO من 0 وRPO من 0، حتى في انقطاع المنطقة. للحصول على معلومات حول RTO، راجع أهداف الاسترداد.
مع تمكين مناطق التوفر، يدعم Azure Cosmos DB ل NoSQL تكوين المنطقة المكررة .
المتطلبات الأساسية
يجب نشر النسخ المتماثلة في منطقة Azure التي تدعم مناطق التوفر. لمعرفة ما إذا كانت منطقتك تدعم مناطق التوفر، راجع قائمة المناطق المدعومة.
تحديد ما إذا كانت مناطق التوفر تضيف قيمة كافية إلى التكوين الحالي في تأثير استخدام مناطق التوفر أم لا.
تأثير استخدام مناطق التوفر
يعتمد تأثير مناطق التوفر على قابلية الوصول العالية لقاعدة بيانات Cosmos DB ل NoSQL على مستوى تناسق الحساب والمناطق التي تم تمكين مناطق التوفر فيها. في كثير من الحالات، لا تضيف مناطق التوفر قيمة أو تضيف قيمة دنيا إذا كان الحساب متعدد المناطق (ما لم يتم تكوينه بتناسق قوي).
راجع الجدول أدناه لتقدير تأثير استخدام مناطق التوفر في تكوين حسابك الحالي:
| مستوى تناسق الحساب | المناطق التي تم تمكين مناطق التوفر فيها | تأثير استخدام مناطق التوفر |
|---|---|---|
| غير متزامن (لا معنى له أو أضعف) | أي عدد من مناطق القراءة الثانوية. | يوفر الحد الأدنى من القيمة لأن SDK يوفر بالفعل عمليات إعادة توجيه سلسة للقراءات عند فشل منطقة قراءة. |
| متزامن (قوي) | منطقتين أو أكثر من مناطق القراءة الثانوية | يوفر قيمة هامشية لأن النظام يمكنه الاستفادة من الحصة الديناميكية إذا فقدت منطقة القراءة التوفر الذي يسمح بمتابعة عمليات الكتابة. |
| متزامن (قوي) | منطقة قراءة ثانوية واحدة | يوفر قيمة أكبر لأن فقدان منطقة قراءة في هذا السيناريو يمكن أن يؤثر على توفر الكتابة. |
| الكل | كتابة المناطق وأي عدد من المناطق الثانوية | يضمن توفرا أكبر لعمليات الكتابة لحالات الفشل في المناطق. |
| الكل | منطقة واحدة | لا يمكن أن تستفيد منطقة واحدة من إمكانية تجاوز الفشل متعددة المناطق. يؤدي استخدام مناطق التوفر إلى الحماية من إجمالي فقدان التوفر بسبب فشل المنطقة. |
تحسينات اتفاقية مستوى الخدمة
نظرا لأن مناطق التوفر منفصلة ماديا وتوفر مصدر طاقة وشبكة وتبريد مميزا، فإن اتفاقيات مستوى الخدمة للتوفر (اتفاقيات مستوى الخدمة) أعلى (99.995٪) من الحسابات التي لها منطقة واحدة (99.99٪). يتم فرض رسوم على المناطق التي يتم تمكين مناطق التوفر فيها بنسبة 25٪ متميزة، في حين أن المناطق التي لا تحتوي على مناطق توفر لا تتحمل قسطا. علاوة على ذلك، يتم التنازل عن التسعير المتميز لمناطق التوفر للحسابات التي تم تكوينها مع عمليات الكتابة متعددة المناطق و/أو للمجموعات التي تم تكوينها باستخدام وضع التحجيم التلقائي.
عادة ما تؤدي إضافة منطقة إضافية إلى حساب Cosmos DB إلى زيادة الفاتورة الحالية بنسبة 100٪ (بشكل إضافي غير مضاعف) على الرغم من وجود تباينات صغيرة في التكلفة عبر المناطق. لمزيد من التفاصيل، راجع صفحة التسعير.
يمكن اعتبار تمكين AZs أو إضافة مناطق (مناطق) إضافية أو تشغيل عمليات الكتابة متعددة المناطق كنهج طبقات يزيد من المرونة وتوافر حساب Cosmos DB معين في كل خطوة من الطريق - من توفر 4 9 لمنطقة واحدة دون تكوين AZ، من خلال 4 ونصف 9 لمنطقة واحدة مع مناطق AZs، وصولا إلى توفر 5 9 للتكوين متعدد المناطق مع تمكين خيار الكتابة متعدد المناطق. يرجى الرجوع إلى الجدول التالي للحصول على ملخص اتفاقيات مستوى الخدمة لكل تكوين.
| مؤشر الأداء الأساسي (KPI) | عمليات الكتابة أحادية المنطقة دون مناطق توفر | عمليات الكتابة أحادية المنطقة مع مناطق التوفر | عمليات الكتابة متعددة المناطق والمنطقة الواحدة دون مناطق توفر | عمليات الكتابة متعددة المناطق والمنطقة الواحدة مع مناطق التوفر | عمليات الكتابة متعددة المناطق، متعددة المناطق مع مناطق التوفر أو بدونها |
|---|---|---|---|---|---|
| اتفاقية على مستوى الخدمة لقابلية الوصول إلى عمليات الكتابة | 99.99% | 99.995% | 99.99% | 99.995% | 99.999% |
| اتفاقية على مستوى الخدمة لقابلية الوصول إلى عمليات القراءة | 99.99% | 99.995% | 99.999% | 99.999% | 99.999% |
| حالات فشل المنطقة: فقدان البيانات | فقدان البيانات | لا يوجد فقدان للبيانات | لا يوجد فقدان للبيانات | لا يوجد فقدان للبيانات | لا يوجد فقدان للبيانات |
| حالات فشل المنطقة: التوفر | فقدان قابلية الوصول | لا يوجد فقدان لقابلية الوصول | لا يوجد فقدان لقابلية الوصول | لا يوجد فقدان لقابلية الوصول | لا يوجد فقدان لقابلية الوصول |
| الانقطاع الإقليمي: فقدان البيانات | فقدان البيانات | فقدان البيانات | يعتمد ذلك على مستوى التناسق. لمزيد من المعلومات، راجع مقايضات التناسق والتوافر والأداء. | يعتمد ذلك على مستوى التناسق. لمزيد من المعلومات، راجع مقايضات التناسق والتوافر والأداء. | يعتمد ذلك على مستوى التناسق. لمزيد من المعلومات، راجع مقايضات التناسق والتوافر والأداء. |
| الانقطاع الإقليمي: التوفر | فقدان قابلية الوصول | فقدان قابلية الوصول | لا يوجد فقدان لقابلية الوصول لعطل في منطقة القراءة، مؤقت لعطل في منطقة الكتابة | لا يوجد فقدان لقابلية الوصول لعطل في منطقة القراءة، مؤقت لعطل في منطقة الكتابة | لا يوجد فقدان في توفر القراءة، فقدان توفر الكتابة المؤقت في المنطقة المتأثرة |
| السعر (1) | غير قابل للتطبيق | وحدة طلب مقدمة/ثانية × معدل 1.25 | وحدات الطلب/ثانية المتوفرة x N المناطق | وحدات الطلب/ثانية المتوفرة × 1.25 معدل x N المناطق (2) | معدل الكتابة متعدد المناطق x N المناطق |
1 بالنسبة للحسابات بلا خادم، يتم ضرب وحدات الطلب بعامل 1.25.
2 ينطبق معدل 1.25 فقط على المناطق التي تقوم فيها بتمكين مناطق التوفر.
إنشاء مورد مع تمكين مناطق التوفر
يمكنك تكوين مناطق التوفر فقط عند إضافة منطقة جديدة إلى حساب Azure Cosmos DB NoSQL.
لتمكين دعم منطقة التوفر، يمكنك استخدام:
الترحيل إلى دعم منطقة التوفر
لمعرفة كيفية ترحيل حساب Cosmos DB إلى دعم منطقة التوفر، راجع ترحيل Azure Cosmos DB ل NoSQL إلى دعم منطقة التوفر).
التعافي من الكوارث عبر المناطق واستمرارية الأعمال
يتعلق التعافي من الكوارث (DR) بالتعافي من الأحداث عالية التأثير، مثل الكوارث الطبيعية أو عمليات النشر الفاشلة التي تؤدي إلى وقت تعطل وفقدان البيانات. بغض النظر عن السبب، فإن أفضل علاج للكارثة هو خطة الإصلاح بعد الكارثة محددة جيدا ومختبرة وتصميم تطبيق يدعم الإصلاح بعد الكارثة بنشاط. قبل البدء في التفكير في إنشاء خطة التعافي من الكوارث، راجع التوصيات لتصميم استراتيجية التعافي من الكوارث.
عندما يتعلق الأمر بالتعافي من الكوارث، تستخدم Microsoft نموذج المسؤولية المشتركة. في نموذج المسؤولية المشتركة، تضمن Microsoft توفر البنية الأساسية الأساسية وخدمات النظام الأساسي. في الوقت نفسه، لا تقوم العديد من خدمات Azure تلقائيا بنسخ البيانات نسخا متماثلا أو الرجوع من منطقة فاشلة للنسخ المتماثل إلى منطقة أخرى ممكنة. بالنسبة إلى هذه الخدمات، أنت مسؤول عن إعداد خطة التعافي من الكوارث التي تعمل مع حمل العمل الخاص بك. توفر معظم الخدمات التي تعمل على عروض النظام الأساسي كخدمة (PaaS) في Azure ميزات وإرشادات لدعم الإصلاح بعد الكارثة ويمكنك استخدام ميزات خاصة بالخدمة لدعم الاسترداد السريع للمساعدة في تطوير خطة الإصلاح بعد الكارثة.
انقطاعات المنطقة هي الانقطاعات التي تؤثر على جميع عقد Azure Cosmos DB في منطقة Azure، عبر جميع مناطق التوفر. بالنسبة للحالات النادرة من انقطاع المنطقة، يمكنك تكوين Azure Cosmos DB لدعم النتائج المختلفة للمتانة والتوافر.
المتانة
عند نشر حساب Azure Cosmos DB في منطقة واحدة، بشكل عام لا يحدث أي فقدان للبيانات. تتم استعادة الوصول إلى البيانات بعد استرداد خدمات Azure Cosmos DB في المنطقة المتأثرة. قد يحدث فقدان البيانات فقط مع كارثة غير قابلة للاسترداد في منطقة Azure Cosmos DB.
لمساعدتك على الحماية من فقدان البيانات الكامل الذي قد ينتج عن الكوارث الكارثية في منطقة ما، يوفر Azure Cosmos DB وضعين للنسخ الاحتياطي:
- النسخ الاحتياطية المستمرة احتياطيا لكل منطقة كل 100 ثانية. فهي تمكنك من استعادة بياناتك إلى أي نقطة زمنية بنقاوة 1 ثانية. في كل منطقة، تعتمد النسخة الاحتياطية على البيانات التي تم الالتزام بها في تلك المنطقة. إذا تم تمكين مناطق التوفر في المنطقة، فسيتم تخزين النسخ الاحتياطي في حسابات التخزين المتكررة في المنطقة.
- النسخ الاحتياطية الدورية تقوم بشكل كامل بنسخ جميع الأقسام من جميع الحاويات ضمن حسابك، دون أي مزامنة عبر الأقسام. الحد الأدنى للفاصل الزمني للنسخة الاحتياطية هو ساعة واحدة.
عند نشر حساب Azure Cosmos DB في مناطق متعددة، تعتمد متانة البيانات على مستوى التناسق الذي تقوم بتكوينه على الحساب. تفاصيل الجدول التالي، لجميع مستويات التناسق، RPO لحساب Azure Cosmos DB الذي تم نشره في منطقتين على الأقل.
| مستوى التناسق | RPO للانقطاع في المنطقة |
|---|---|
| جلسة عمل، بادئة متسقة، نهائية | أقل من 15 دقيقة |
| مستمر بلا حدود "Bounded Staleness" | K وT |
| قوي "Strong" | 0 |
K = عدد الإصدارات (أي التحديثات) لعنصر ما.
T = الفاصل الزمني منذ آخر تحديث.
بالنسبة للحسابات متعددة المناطق، فإن الحد الأدنى لقيمة K وT هو 100000 عملية كتابة أو 300 ثانية. تحدد هذه القيمة الحد الأدنى من RPO للبيانات عند استخدام bounded staleness.
لمزيد من المعلومات حول الاختلافات بين مستويات التناسق، راجع مستويات التناسق في Azure Cosmos DB.
تجاوز الفشل المدار بواسطة الخدمة
إذا كان الحل الخاص بك يتطلب وقت تشغيل مستمر أثناء انقطاع المنطقة، يمكنك تكوين Azure Cosmos DB لنسخ بياناتك عبر مناطق متعددة وتجاوز الفشل بشفافية إلى مناطق التشغيل عند الحاجة.
قد تفقد الحسابات أحادية المنطقة إمكانية الوصول بعد انقطاع إقليمي. لضمان استمرارية الأعمال في جميع الأوقات، نوصي بإعداد حساب Azure Cosmos DB الخاص بك مع منطقة كتابة واحدة ومنطقة ثانية على الأقل (قراءة) وتمكين تجاوز الفشل المدار بواسطة الخدمة.
يسمح تجاوز الفشل المدار بواسطة الخدمة ل Azure Cosmos DB بالفشل عبر منطقة الكتابة لحساب متعدد المناطق من أجل الحفاظ على استمرارية الأعمال على حساب فقدان البيانات، كما هو موضح سابقا في قسم المتانة . يتم اكتشاف حالات تجاوز الأعطال على النطاق الإقليمي ومعالجتها في عميل Azure Cosmos DB. لا تتطلب أي تغييرات من التطبيق. للحصول على إرشادات حول كيفية تمكين مناطق قراءة متعددة وتجاوز الفشل المدار بواسطة الخدمة، راجع إدارة حساب Azure Cosmos DB باستخدام مدخل Microsoft Azure.
هام
إذا اخترت تكوين كتابة منطقة واحدة مع مناطق قراءة متعددة، نوصي بشدة بتكوين حسابات Azure Cosmos DB المستخدمة لأحمال عمل الإنتاج لتمكين تجاوز الفشل المدار بواسطة الخدمة. يمكن هذا التكوين Azure Cosmos DB من الفشل عبر قواعد بيانات الحساب إلى المناطق المتوفرة. في حالة عدم وجود هذا التكوين، سيعاني الحساب من فقدان توفر الكتابة طوال مدة انقطاع منطقة الكتابة. لن ينجح تجاوز الفشل اليدوي بسبب نقص الاتصال بالمنطقة.
تحذير
حتى مع تمكين تجاوز الفشل المدار بواسطة الخدمة، قد يتطلب الانقطاع الجزئي تدخلا يدويا لفريق خدمة Azure Cosmos DB. في هذه السيناريوهات، قد يستغرق الأمر ما يصل إلى ساعة واحدة (أو أكثر) حتى يدخل تجاوز الفشل حيز التنفيذ. للحصول على توفر أفضل للكتابة أثناء الانقطاع الجزئي، نوصي بتمكين مناطق التوفر بالإضافة إلى تجاوز الفشل المدار بواسطة الخدمة.
مناطق كتابة متعددة
يمكنك تكوين Azure Cosmos DB لقبول عمليات الكتابة في مناطق متعددة. هذا التكوين مفيد لتقليل زمن انتقال الكتابة في التطبيقات الموزعة جغرافيا.
عند تكوين حساب Azure Cosmos DB لمناطق كتابة متعددة، لا يتم دعم التناسق القوي وقد تنشأ تعارضات في الكتابة. لمزيد من المعلومات حول كيفية حل هذه التعارضات، راجع أنواع التعارضات ونهج الحل عند استخدام مناطق كتابة متعددة.
هام
تحديث معرف المستند نفسه بشكل متكرر (أو إعادة إنشاء معرف المستند نفسه بشكل متكرر بعد TTL أو حذفه) سيكون له تأثير على أداء النسخ المتماثل بسبب زيادة عدد التعارضات التي تم إنشاؤها في النظام.
منطقة حل النزاعات
عند تكوين حساب Azure Cosmos DB مع عمليات الكتابة متعددة المناطق، ستعمل إحدى المناطق كحكم في تعارضات الكتابة.
أفضل الممارسات للكتابات متعددة المناطق
فيما يلي بعض أفضل الممارسات التي يجب مراعاتها عند الكتابة إلى مناطق متعددة.
الاحتفاظ بحركة المرور المحلية المحلية
عند استخدام عمليات الكتابة متعددة المناطق، يجب أن يصدر التطبيق نسبة استخدام الشبكة للقراءة والكتابة التي تنشأ في المنطقة المحلية بدقة إلى منطقة Cosmos DB المحلية. للحصول على الأداء الأمثل، تجنب المكالمات عبر المناطق.
من المهم للتطبيق تقليل التعارضات عن طريق تجنب مضادات التناثر التالية:
إرسال نفس عملية الكتابة إلى جميع المناطق لزيادة احتمالات الحصول على وقت استجابة سريع
تحديد المنطقة المستهدفة بشكل عشوائي لعملية قراءة أو كتابة على أساس كل طلب
استخدام نهج الترتيب الدوري لتحديد المنطقة المستهدفة لعملية القراءة أو الكتابة على أساس كل طلب.
تجنب التبعية على تأخر النسخ المتماثل
لا يمكنك تكوين حسابات الكتابة متعددة المناطق للاتساق القوي. المنطقة التي تتم كتابتها للاستجابة مباشرة بعد أن يقوم Azure Cosmos DB بنسخ البيانات نسخا متماثلا محليا أثناء نسخ البيانات بشكل غير متزامن عالميا.
على الرغم من أنه غير متكرر، فقد يحدث تأخر النسخ المتماثل على قسم واحد أو بعض الأقسام عندما تقوم بالنسخ المتماثل الجغرافي للبيانات. يمكن أن يحدث تأخر النسخ المتماثل بسبب وجود شوائب نادرة في نسبة استخدام الشبكة أو معدلات أعلى من المعتاد لحل التعارض.
على سبيل المثال، تقدم البنية التي يكتب فيها التطبيق إلى المنطقة A ولكنها تقرأ من المنطقة B تبعية على تأخر النسخ المتماثل بين المنطقتين. ومع ذلك، إذا كان التطبيق يقرأ ويكتب إلى نفس المنطقة، يظل الأداء ثابتا حتى في وجود تأخر النسخ المتماثل.
تقييم استخدام تناسق الجلسة لعمليات الكتابة
في تناسق الجلسة، يمكنك استخدام الرمز المميز للجلسة لكل من عمليات القراءة والكتابة.
لعمليات القراءة، يرسل Azure Cosmos DB رمز الجلسة المخزن مؤقتا إلى الخادم مع ضمان تلقي البيانات التي تتوافق مع رمز الجلسة المحدد (أو الأحدث).
لعمليات الكتابة، يرسل Azure Cosmos DB رمز الجلسة المميز إلى قاعدة البيانات مع ضمان استمرار البيانات فقط إذا كان الخادم قد اشتعل إلى الرمز المميز للجلسة المقدمة. في حسابات الكتابة أحادية المنطقة، يضمن دائما أن تكون منطقة الكتابة قد اشتعلت في الرمز المميز للجلسة. ومع ذلك، في حسابات الكتابة متعددة المناطق، قد لا تكون المنطقة التي تكتب إليها قد لا تصل إلى عمليات الكتابة الصادرة إلى منطقة أخرى. إذا كتب العميل إلى المنطقة (أ) برمز جلسة مميز من المنطقة (ب)، فلن تتمكن المنطقة (أ) من الاحتفاظ بالبيانات حتى تصل إلى التغييرات التي تم إجراؤها في المنطقة (ب).
من الأفضل استخدام الرموز المميزة للجلسة فقط لعمليات القراءة وليس لعمليات الكتابة عند تمرير رموز الجلسة المميزة بين مثيلات العميل.
التخفيف من حدة التحديثات السريعة لنفس المستند
يمكن أن تتصادم تحديثات الخادم لحل أو تأكيد عدم وجود تعارضات مع عمليات الكتابة التي يشغلها التطبيق عند تحديث المستند نفسه بشكل متكرر. تواجه التحديثات المتكررة في تتابع سريع لنفس المستند زمن انتقال أعلى أثناء حل التعارض.
على الرغم من أن الاندفاعات العرضية في التحديثات المتكررة لنفس المستند أمر لا مفر منه، فقد تفكر في استكشاف بنية حيث يتم إنشاء مستندات جديدة بدلا من ذلك إذا شهدت حركة مرور الحالة الثابتة تحديثات سريعة لنفس المستند على مدى فترة طويلة.
انقطاع القراءة والكتابة
سيعاني عملاء حسابات المنطقة الواحدة من فقدان توفر القراءة والكتابة حتى تتم استعادة الخدمة.
تواجه الحسابات متعددة المناطق سلوكيات مختلفة اعتمادا على التكوينات وأنواع الانقطاع التالية.
| التكوين | انقطاع | تأثير التوافر | تأثير القدرة على الصمود | ما يجب القيام به |
|---|---|---|---|---|
| منطقة كتابة فردية | قراءة انقطاع المنطقة | يقوم جميع العملاء تلقائيا بإعادة توجيه القراءات إلى مناطق أخرى. لا يوجد فقدان في توفر القراءة أو الكتابة لجميع التكوينات. الاستثناء هو تكوين منطقتين مع تناسق قوي، والذي يفقد توفر الكتابة حتى استعادة الخدمة. أو، إذا قمت بتمكين تجاوز الفشل المدار بواسطة الخدمة، فإن الخدمة تحدد المنطقة على أنها فاشلة ويحدث تجاوز فشل. | لا يوجد فقدان للبيانات. | أثناء الانقطاع، تأكد من وجود عدد كاف من وحدات الطلب المتوفرة (RUs) في المناطق المتبقية لدعم حركة مرور القراءة. عند انتهاء الانقطاع، قم إعادة ضبط وحدات الطلب المقدمة حسب الاقتضاء. |
| منطقة كتابة فردية | انقطاع منطقة الكتابة | يعيد العملاء توجيه القراءات إلى مناطق أخرى. دون تجاوز الفشل المدار بواسطة الخدمة، يواجه العملاء فقدان توفر الكتابة. تتم استعادة توفر الكتابة تلقائيا عند انتهاء الانقطاع. مع تجاوز الفشل المدار بواسطة الخدمة، يواجه العملاء فقدان توفر الكتابة حتى تدير الخدمة تجاوز الفشل إلى منطقة كتابة جديدة تحددها. |
إذا لم تحدد مستوى التناسق القوي، فقد لا تقوم الخدمة بنسخ بعض البيانات نسخا متماثلا إلى المناطق النشطة المتبقية. يعتمد هذا النسخ المتماثل على مستوى التناسق الذي تحدده. إذا عانت المنطقة المتأثرة من فقدان دائم للبيانات، فقد تفقد بيانات غير مبسطة. | أثناء انقطاع التيار الكهربائي، تأكد من وجود عدد كاف من وحدات الطلب المقدمة في المناطق المتبقية لدعم حركة بيانات القراءة. لا تقم بتشغيل تجاوز فشل يدوي أثناء الانقطاع، لأنه لا يمكن أن ينجح. عند انتهاء الانقطاع، قم إعادة ضبط وحدات الطلب المقدمة حسب الاقتضاء. قد تسترد الحسابات التي تستخدم واجهة برمجة التطبيقات ل NoSQL أيضا البيانات غير المبسطة في المنطقة الفاشلة من موجز التعارض الخاص بك. |
| مناطق كتابة متعددة | الانقطاع الإقليمي | هناك إمكانية فقدان مؤقت لتوافر الكتابة، وهو مماثل لمنطقة كتابة واحدة مع تجاوز الفشل المدار بواسطة الخدمة. قد يتسبب تجاوز فشل منطقة حل التعارض أيضا في فقدان توفر الكتابة إذا حدث عدد كبير من عمليات الكتابة المتعارضة في وقت الانقطاع. | قد تكون البيانات المحدثة مؤخرا في المنطقة الفاشلة غير متوفرة في المناطق النشطة المتبقية، اعتمادا على مستوى التناسق المحدد. إذا عانت المنطقة المتأثرة من فقدان دائم للبيانات، فقد تفقد بيانات غير مبسطة. | أثناء الانقطاع، تأكد من وجود عدد كاف من وحدات الطلب المتوفرة في المناطق المتبقية لدعم المزيد من حركة المرور. عند انتهاء الانقطاع، يمكنك إعادة ضبط وحدات الطلب المتوفرة حسب الاقتضاء. إذا كان ذلك ممكنا، يقوم Azure Cosmos DB تلقائيا باسترداد البيانات غير المبسطة في المنطقة الفاشلة. يستخدم هذا الاسترداد التلقائي أسلوب حل التعارض الذي تقوم بتكوينه للحسابات التي تستخدم واجهة برمجة التطبيقات ل NoSQL. بالنسبة للحسابات التي تستخدم واجهات برمجة التطبيقات الأخرى، يستخدم هذا الاسترداد التلقائي آخر انتصارات الكتابة. |
معلومات إضافية حول انقطاعات منطقة القراءة
المنطقة المتأثرة غير متصلة وتم وضع علامة عليها دون اتصال. تعيد Azure Cosmos DB SDKs توجيه استدعاءات القراءة إلى المنطقة المتوفرة التالية في قائمة المنطقة المفضلة.
إذا لم تتوفر أي من المناطق في قائمة المناطق المفضلة، فإن المكالمات تعود تلقائيا إلى منطقة الكتابة الحالية.
لا توجد تغييرات مطلوبة في التعليمات البرمجية للتطبيق لمعالجة انقطاعات منطقة القراءة. عندما تكون منطقة القراءة المتأثرة متصلة مرة أخرى، فإنها تتم مزامنتها مع منطقة الكتابة الحالية وتتوفر مرة أخرى لخدمة طلبات القراءة بعد أن يتم اكتشافها بالكامل.
تتم إعادة توجيه القراءات اللاحقة إلى المنطقة التي تسترد اتصالها بدون الحاجة إلى إجراء أي تعديلات على التعليمات البرمجية للتطبيق الخاص بك. أثناء كل من تجاوز الفشل وإعادة الانضمام إلى منطقة فاشلة سابقا، يستمر Azure Cosmos DB في الالتزام بضمانات تناسق القراءة.
حتى في حدث نادر ومؤسف حيث تكون منطقة كتابة Azure غير قابلة للاسترداد بشكل دائم، لا يوجد فقدان للبيانات إذا تم تكوين حساب Azure Cosmos DB متعدد المناطق بتناسق قوي. يحتوي حساب Azure Cosmos DB متعدد المناطق على خصائص المتانة المحددة سابقا في قسم المتانة.
معلومات إضافية حول انقطاعات منطقة القراءة
أثناء انقطاع منطقة الكتابة، يقوم حساب Azure Cosmos DB بترقية منطقة ثانوية لتكون منطقة الكتابة الأساسية الجديدة عند تكوين تجاوز الفشل المدار بواسطة الخدمة على حساب Azure Cosmos DB. يحدث تجاوز الفشل لمنطقة أخرى بترتيب أولوية المنطقة التي تحددها.
لا يجب تشغيل تجاوز الفشل اليدوي ولن ينجح في وجود انقطاع في منطقة المصدر أو الوجهة. والسبب هو أن إجراء تجاوز الفشل يتضمن فحص التناسق الذي يتطلب الاتصال بين المناطق.
عندما تكون المنطقة المتأثرة سابقا متصلة مرة أخرى، يتم توفير أي بيانات كتابة لم يتم نسخها نسخا متماثلا عند فشل المنطقة من خلال موجز التعارض. يمكن للتطبيقات قراءة موجز التعارض، وحل التعارضات استنادا إلى المنطق الخاص بالتطبيق، وكتابة البيانات المحدثة مرة أخرى إلى حاوية Azure Cosmos DB حسب الاقتضاء.
بعد استرداد منطقة الكتابة المتأثرة سابقا، ستظهر على أنها "متصلة" في مدخل Microsoft Azure، وتصبح متاحة كمنطقة قراءة. في هذه المرحلة، من الآمن العودة إلى المنطقة المستردة كمنطقة كتابة باستخدام [PowerShell أو Azure CLI أو مدخل Azure](.. /cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account. لا يوجد فقدان للبيانات أو التوفر قبل تبديل منطقة الكتابة أو أثناءها أو بعدها. لا يزال تطبيقك متوفرا بشكل كبير.
تحذير
في حالة انقطاع منطقة الكتابة، حيث يقوم حساب Azure Cosmos DB بترقية منطقة ثانوية لتكون منطقة الكتابة الأساسية الجديدة عبر تجاوز الفشل المدار بواسطة الخدمة، لن تتم ترقية منطقة الكتابة الأصلية مرة أخرى كمنطقة الكتابة تلقائيا بمجرد استردادها. تقع على عاتقك مسؤولية العودة إلى المنطقة المستردة كمنطقة كتابة باستخدام PowerShell أو Azure CLI أو مدخل Microsoft Azure (بمجرد أن يكون ذلك آمنا، كما هو موضح أعلاه).
الكشف عن الانقطاع والإعلام والإدارة
بالنسبة إلى حسابات المنطقة الواحدة، يواجه العملاء فقدان توفر القراءة والكتابة أثناء انقطاع منطقة Azure Cosmos DB. تواجه الحسابات متعددة المناطق سلوكيات مختلفة، كما هو موضح في الجدول التالي.
| مناطق الكتابة | تجاوز الفشل المدار بواسطة الخدمة | ما المتوقع | ما يجب القيام به |
|---|---|---|---|
| منطقة كتابة فردية | غير ممكّن | إذا كان هناك انقطاع في منطقة القراءة عندما لا تستخدم تناسقا قويا، فإن جميع العملاء يعيدون التوجيه إلى مناطق أخرى. لا يوجد فقدان في قابلية الوصول للقراءة أو الكتابة، ولا يوجد فقدان للبيانات. عند استخدام تناسق قوي، يمكن أن يؤثر الانقطاع في منطقة القراءة على توفر الكتابة إذا بقيت أقل من منطقتين للقراءة. إذا كان هناك انقطاع في منطقة الكتابة، يواجه العملاء فقدان توفر الكتابة. إذا لم تحدد تناسقا قويا، فقد لا تقوم الخدمة بنسخ بعض البيانات نسخا متماثلا إلى المناطق النشطة المتبقية. يعتمد هذا النسخ المتماثل على مستوى التناسق المحدد. إذا عانت المنطقة المتأثرة من فقدان دائم للبيانات، فقد تفقد بيانات غير مبسطة. يستعيد Azure Cosmos DB توفر الكتابة عند انتهاء الانقطاع. |
أثناء انقطاع التيار الكهربائي، تأكد من وجود عدد كاف من وحدات الطلب المقدمة في المناطق المتبقية لدعم حركة بيانات القراءة. لا تقم بتشغيل تجاوز فشل يدوي أثناء الانقطاع، لأنه لا يمكن أن ينجح. عند انتهاء الانقطاع، قم إعادة ضبط وحدات الطلب المقدمة حسب الاقتضاء. |
| منطقة كتابة فردية | مُمَكّن | إذا كان هناك انقطاع في منطقة القراءة عندما لا تستخدم تناسقا قويا، فإن جميع العملاء يعيدون التوجيه إلى مناطق أخرى. لا يوجد فقدان في قابلية الوصول للقراءة أو الكتابة، ولا يوجد فقدان للبيانات. عندما تستخدم تناسقا قويا، يمكن أن يؤثر انقطاع منطقة القراءة على توفر الكتابة إذا بقيت أقل من منطقتين للقراءة. إذا كان هناك انقطاع في منطقة الكتابة، يواجه العملاء فقدان توفر الكتابة حتى يختار Azure Cosmos DB منطقة جديدة كمنطقة كتابة جديدة وفقا لتفضيلاتك. إذا لم تحدد تناسقا قويا، فقد لا تقوم الخدمة بنسخ بعض البيانات نسخا متماثلا إلى المناطق النشطة المتبقية. يعتمد هذا النسخ المتماثل على مستوى التناسق المحدد. إذا عانت المنطقة المتأثرة من فقدان دائم للبيانات، فقد تفقد بيانات غير مبسطة. |
أثناء انقطاع التيار الكهربائي، تأكد من وجود عدد كاف من وحدات الطلب المقدمة في المناطق المتبقية لدعم حركة بيانات القراءة. لا تقم بتشغيل تجاوز فشل يدوي أثناء الانقطاع، لأنه لا يمكن أن ينجح. عند انتهاء الانقطاع، يمكنك نقل منطقة الكتابة مرة أخرى إلى المنطقة الأصلية وإعادة ضبط وحدات الطلب المقدمة حسب الاقتضاء. يمكن للحسابات التي تستخدم واجهة برمجة التطبيقات ل NoSQL أيضا استرداد البيانات غير المبسطة في المنطقة الفاشلة من موجز التعارض الخاص بك. |
| مناطق كتابة متعددة | غير قابل للتطبيق | قد لا تتوفر البيانات التي تم تحديثها مؤخرا في المنطقة الفاشلة في المناطق النشطة المتبقية. تضمن مستويات البادئة النهائية والمتناسقة وتناسق الجلسة ثباتا أقل من 15 دقيقة. يضمن Bounded staleness أقل من تحديثات K أو ثواني T ، اعتمادا على التكوين. إذا عانت المنطقة المتأثرة من فقدان دائم للبيانات، فقد تفقد بيانات غير مبسطة. | أثناء الانقطاع، تأكد من وجود عدد كاف من وحدات الطلب المتوفرة في المناطق المتبقية لدعم المزيد من حركة المرور. عند انتهاء الانقطاع، يمكنك إعادة ضبط وحدات الطلب المتوفرة حسب الاقتضاء. إذا كان ذلك ممكنا، يسترد Azure Cosmos DB البيانات غير المبسطة في المنطقة الفاشلة. يستخدم هذا الاسترداد أسلوب حل التعارض الذي تقوم بتكوينه للحسابات التي تستخدم واجهة برمجة التطبيقات ل NoSQL. بالنسبة للحسابات التي تستخدم واجهات برمجة التطبيقات الأخرى، يستخدم هذا الاسترداد آخر انتصارات الكتابة. |
اختبار قابلية الوصول العالية
حتى إذا كان حساب Azure Cosmos DB الخاص بك متوفرا بشكل كبير، فقد لا يكون التطبيق الخاص بك مصمما بشكل صحيح ليظل متوفرا بشكل كبير. لاختبار قابلية الوصول العالية من طرف إلى طرف لتطبيقك كجزء من اختبار التطبيق أو تدريبات التعافي من الكوارث (DR)، قم بتعطيل تجاوز الفشل المدار بواسطة الخدمة للحساب مؤقتا. استدعاء تجاوز الفشل اليدوي باستخدام PowerShell أو Azure CLI أو مدخل Microsoft Azure، ثم مراقبة التطبيق الخاص بك. بعد إكمال الاختبار، يمكنك العودة إلى المنطقة الأساسية واستعادة تجاوز الفشل المدار بواسطة الخدمة للحساب.
هام
لا تستدعي تجاوز الفشل اليدوي أثناء انقطاع Azure Cosmos DB على منطقة المصدر أو الوجهة. يتطلب تجاوز الفشل اليدوي اتصال المنطقة للحفاظ على تناسق البيانات، لذلك لن ينجح.