الموثوقية في Azure Cosmos DB

Azure Cosmos DB NoSQL هي خدمة قاعدة بيانات متعددة النماذج موزعة عالميا تدعم نماذج بيانات المستندات ذات المخططات المرنة. يوفر Azure Cosmos DB ميزات موثوقية شاملة بما في ذلك مستويات تناسق متعددة تتيح لك تحقيق التوازن بين الأداء والتوافر، والنشرات المتكررة في المنطقة التي تحمي من حالات فشل منطقة التوفر، والنسخ المتماثل متعدد المناطق مع تجاوز الفشل المدار بواسطة الخدمة أو الذي يديره العميل، وخيارات النسخ الاحتياطي المستمر والدوري لحماية البيانات.

عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.

توضح هذه المقالة كيفية جعل Azure Cosmos DB مرنة في مواجهة حالات الانقطاع والمشاكل المحتملة المختلفة، بما في ذلك الأخطاء العابرة وانقطاعات منطقة التوفر وانقطاع المنطقة وصيانة الخدمة. كما يصف كيفية استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشكلات ويسلط الضوء على المعلومات الرئيسية حول اتفاقية مستوى الخدمة Azure Cosmos DB (SLA).

توصيات نشر الإنتاج

يوفر إطار عمل Azure Well-Architected توصيات عبر الموثوقية والأمان والتكلفة والعمليات والأداء. لفهم كيفية تأثير هذه المجالات على بعضها البعض والمساهمة في حل Azure Cosmos DB موثوق به، راجع أفضل ممارسات البنية Azure Cosmos DB.

نظرة عامة على بنية الموثوقية

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

البنية المنطقية

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

يمكنك تكوين معدل النقل، والذي يمثل مقدار موارد النظام التي يمكنك استخدامها للاستعلام عن بياناتك والعمل معها. يمكنك توفير معدل النقل يدويا، أو استخدام مقياس تلقائي لضبط السعة ديناميكيا استنادا إلى متطلبات حمل العمل الخاص بك، أو استخدام نوع الحساب بلا خادم ليتم تحصيل رسوم مقابل استخدامك الفعلي.

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

العمارة المادية

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

داخليا، يدير Azure Cosmos DB بياناتك من خلال بنيات مختلفة بما في ذلك الأقسام الماديةومجموعات الأقسامومجموعات النسخ المتماثلة. لمزيد من المعلومات التفصيلية حول كيفية عمل Azure Cosmos DB، راجع توزيع البيانات العالمية مع Azure Cosmos DB - تحت الغطاء.

المرونة في مواجهة الأعطال العابرة

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

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

استخدم Azure Cosmos DB SDKs. تنفذ SDKs الدعم تلقائيا لمجموعة من اعتبارات المرونة، بما في ذلك معالجة الأخطاء العابرة من خلال عمليات إعادة المحاولة التلقائية، وتلبية استجابات حد المعدل المرسلة من قبل الخدمة. لمزيد من المعلومات، راجع تصميم تطبيقات مرنة باستخدام Azure Cosmos DB SDKs.

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

المرونة في مواجهة حالات فشل منطقة التوفر

مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.

يدعم Azure Cosmos DB تكرار المنطقة. عند تمكين تكرار المنطقة، يوزع Azure النسخ المتماثلة لبياناتك عبر مناطق توفر متعددة، ما يوفر مرونة لمشاكل مراكز البيانات وانقطاعاتها. يحدد Microsoft مناطق التوفر لاستخدامها.

رسم تخطيطي يوضح حساب Azure Cosmos DB مع مجموعة نسخ متماثلة تحتوي على ثلاث نسخ متماثلة، والتي يتم توزيعها عبر ثلاث مناطق توفر منفصلة.

قد يستخدم حساب Azure Cosmos DB مناطق متعددة (مواقع) للتوزيع العالمي والمقياس وتجاوز الفشل. يمكنك تكوين تكرار المنطقة بشكل منفصل لكل منطقة في حسابك.

استخدام تكرار المنطقة في Azure Cosmos DB ليس له تأثير ملحوظ على الأداء أو زمن الانتقال. لا يتطلب أي تعديلات على وضع التناسق المحدد، ولا يتطلب أي تعديل على التعليمات البرمجية للتطبيق.

استخدم تكرار المنطقة في المناطق التي يتم دعمها فيها، خاصة لحسابات المنطقة الواحدة. نظرا لأن مناطق التوفر منفصلة ماديا وتوفر مصادر طاقة وشبكات وتبريد مميزة، فإن اتفاقيات مستوى الخدمة لقابلية الوصول Azure Cosmos DB أعلى للحسابات المتكررة في المنطقة من الحسابات التي لا تستخدم مناطق التوفر.

نصيحة

يعد تمكين التكرار في المنطقة طريقة رائعة لزيادة مرونة قاعدة البيانات Azure Cosmos DB دون إدخال تعقيدات إضافية للتطبيق أو التأثير على الأداء. اعتمادا على تكوين حسابك، قد لا يتحمل تكاليف إضافية.

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

المتطلبات

  • دعم المنطقة: يمكنك تمكين تكرار المنطقة في مناطق Azure التي تدعم مناطق التوفر. لمعرفة ما إذا كانت منطقتك تدعم مناطق التوفر، راجع قائمة المناطق المدعومة.

    التكرار في المنطقة ليس إعدادا على مستوى الحساب. يمكن أن تمتد حسابات Azure Cosmos DB عبر مناطق متعددة، ويمكن تكوين كل منطقة بشكل مستقل لاستخدام مناطق التوفر. لا تمنعك المناطق التي لا تدعم مناطق التوفر من تمكين تكرار المنطقة في مناطق أخرى داخل نفس الحساب.

  • الحسابات بلا خادم: يمكنك فقط تكوين حسابات المنطقة المكررة بدون خادم عند إنشائها. لا يمكنك تحويل حسابات بلا خادم موجودة دون مناطق توفر إلى تكوين منطقة توفر. بالنسبة لأحمال العمل الحرجة للمهام، استخدم معدل النقل المقدم.

Considerations

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

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

Cost

يتم فرض رسوم على المناطق التي يتم فيها تمكين تكرار المنطقة مقابل قسط. ومع ذلك، يتم التنازل عن التسعير المتميز لمناطق التوفر للحسابات التي تم تكوينها مع عمليات الكتابة متعددة المناطق، والمجموعات التي تم تكوينها لاستخدام وضع معدل النقل للتحجيم التلقائي. لمزيد من المعلومات، راجع تسعير Azure Cosmos DB.

تكوين دعم منطقة التوفر

بالنسبة لمعظم الحسابات، يمكنك تمكين تكرار المنطقة فقط عند إضافة منطقة جديدة إلى حساب Azure Cosmos DB. لتمكين دعم منطقة التوفر على حساب موجود، أضف منطقة وقم بتمكين تكرار المنطقة عليها. يمكنك اتباع عملية لإضافة منطقة مؤقتة بحيث يمكنك تكوين تكرار المنطقة في منطقتك الأصلية. للحصول على خطوات مفصلة، راجع تمكين تكرار المنطقة على حساب Azure Cosmos DB.

بالنسبة للحسابات بلا خادم، يجب تمكين تكرار المنطقة عند إنشاء الحساب.

السلوك عندما تكون جميع المناطق صحية

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB لتكرار المنطقة، وتكون جميع المناطق قيد التشغيل.

  • العملية عبر المناطق: Azure Cosmos DB توجيه الطلبات تلقائيا إلى النسخ المتماثلة عبر مناطق التوفر، بحيث يمكن لأي نسخة متماثلة تقديم طلب.

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

السلوك أثناء فشل المنطقة

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB لتكرار المنطقة، وهناك انقطاع في إحدى المناطق.

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

  • فقدان البيانات المتوقع: لا يوجد فقدان متوقع للبيانات من فشل المنطقة.

  • وقت التعطل المتوقع: أثناء انقطاع المنطقة، قد تواجه الاتصالات انقطاعات قصيرة تستمر عادة بضع ثوان مع إعادة توزيع حركة المرور. تأكد من إعداد تطبيقاتك باتباع إرشادات معالجة الأعطال العابرة.

  • إعادة التوزيع: يعيد Azure Cosmos DB توجيه الطلبات الواردة تلقائيا إلى النسخ المتماثلة السليمة في مناطق التوفر الأخرى. عندما يكون هناك انقطاع في منطقة التوفر، يعيد النظام الأساسي تلقائيا تخصيص معدل النقل المقدم إلى النسخ المتماثلة الأخرى.

استعادة المنطقة

عند استرداد منطقة التوفر، Azure Cosmos DB تلقائيا استعادة النسخ المتماثلة في منطقة التوفر، وإعادة توجيه نسبة استخدام الشبكة بين النسخ المتماثلة كالمعتاد.

اختبار فشل المنطقة

تتم إدارة تجاوز فشل منطقة التوفر واستردادها Azure Cosmos DB بالكامل بواسطة Microsoft. لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها.

القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة

عند نشر حساب Azure Cosmos DB في منطقة واحدة، لا يتسبب الانقطاع على مستوى المنطقة الذي يؤثر على جميع العقد Azure Cosmos DB عادة في فقدان البيانات، ولكنه يمنع تطبيقك من الوصول إلى البيانات. Azure Cosmos DB استعادة الوصول إلى البيانات بعد استرداد الخدمة في المنطقة المتأثرة. يحدث فقدان البيانات فقط إذا واجهت المنطقة كارثة غير قابلة للاسترداد.

للتحضير للحالات النادرة من انقطاع المنطقة، يمكنك تكوين Azure Cosmos DB لدعم مستويات مختلفة من المتانة والتوافر باستخدام أحد هذه الأساليب:

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

الإعداد نوع الانقطاع تأثير التوفر تأثير المتانة ما يجب فعله
حساب منطقة واحدة انقطاع المنطقة يتم فقدان الوصول للقراءة والكتابة حتى تتم استعادة الخدمة. لا يوجد فقدان للبيانات ما لم تواجه المنطقة كارثة غير قابلة للاسترداد. انتظر استعادة الخدمة أو اطلب استعادة الحساب من النسخ الاحتياطي إلى منطقة أخرى.
حساب منطقة كتابة واحدة، حساب متعدد المناطق قراءة انقطاع المنطقة تعيد SDK توجيهها إلى المناطق المتوفرة استنادا إلى تكوين المناطق المفضلة.

بالنسبة للحسابات التي تستخدم تناسقا قويا مع منطقتين فقط أو حدود لا معنى لها تتجاوز نافذة الثبات، يتم أيضا فقدان توفر الكتابة ما لم تأخذ المنطقة المتأثرة دون اتصال.
لا يوجد فقدان للبيانات. ضمان معدل نقل كاف في المناطق المتبقية. للحصول على تناسق قوي أو محدد، ضع في اعتبارك عدم الاتصال بالمنطقة المتأثرة.
حساب منطقة كتابة واحدة، حساب متعدد المناطق انقطاع المنطقة (مع تفعيل PPAF) تجاوز الفشل التلقائي على مستوى القسم؛ لا حاجة إلى تدخل يدوي. إذا كان الحساب يستخدم تناسقا قويا، فلا يوجد فقدان للبيانات. إذا لم يستخدم الحساب تناسقا قويا، فقد يتم فقدان البيانات غير المبسطة في حالة تعرض المنطقة لفقدان دائم للبيانات. لا يوجد إجراء مطلوب. يدير PPAF تجاوز الفشل تلقائيا.
حساب منطقة كتابة واحدة، حساب متعدد المناطق انقطاع المنطقة (بدون PPAF) يتم فقدان توفر الكتابة حتى تكتمل عملية عدم الاتصال أو تجاوز الفشل المدار بواسطة الخدمة. تستمر القراءات من المناطق السليمة. إذا كان الحساب يستخدم تناسقا قويا، فلا يوجد فقدان للبيانات. إذا لم يستخدم الحساب تناسقا قويا، فقد يتم فقدان البيانات غير المبسطة في حالة تعرض المنطقة لفقدان دائم للبيانات. تنفيذ عملية غير متصلة بالمنطقة. إذا تم تمكين تجاوز الفشل المدار بواسطة الخدمة، Azure Cosmos DB يبدأ تجاوز الفشل تلقائيا، ولكن قد يستغرق ذلك ساعة واحدة أو أكثر. لا تغير منطقة الكتابة أثناء الانقطاع.
حساب المناطق متعدد الكتابة أي انقطاع في المنطقة التوجيه التلقائي إلى المناطق السليمة عبر تكوين SDK؛ لا حاجة إلى تدخل يدوي. قد لا تتوفر البيانات المحدثة مؤخرا في المنطقة الفاشلة في المناطق المتبقية. في حالة تعرض المنطقة لفقدان دائم للبيانات، قد تفقد بيانات غير مبسطة. ضمان معدل نقل كاف في المناطق المتبقية. بعد الاسترداد، Azure Cosmos DB تلقائيا استرداد البيانات غير المبسطة باستخدام أسلوب حل التعارض الذي تم تكوينه.
أي تكوين حساب تلف البيانات أو الحذف العرضي لا يوجد تأثير على التوفر. فقدان البيانات المحتمل استنادا إلى وقت الكشف عن التلف أو الحذف. استعادة نقطة زمنية (النسخ الاحتياطي المستمر) أو الاستعادة من النسخ الاحتياطي الدوري.

ملحوظة

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

SDKs والمرونة

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

لمزيد من المعلومات حول كيفية دعم SDK لقابلية الوصول العالية، راجع وثائق قابلية الوصول العالية ل SDK التي تستخدمها:

فقدان محتمل للبيانات أثناء انقطاع المنطقة

عند نشر حساب Azure Cosmos DB في مناطق متعددة، تعتمد متانة البيانات على مستوى التناسق الذي تقوم بتكوينه على الحساب. تفاصيل الجدول التالي، لجميع مستويات التناسق، هدف نقطة الاسترداد (RPO) لحساب Azure Cosmos DB الذي تم نشره في منطقتين على الأقل. يمثل RPO فقدان البيانات المحتمل أثناء انقطاع المنطقة.

مستوى التناسق RPO للانقطاع في المنطقة
جلسة عمل، بادئة متسقة، نهائية أقل من 15 دقيقة
الجمود المحدود كوتي
قويه 0

K = عدد الإصدارات (أي التحديثات) لعنصر.

T = الفاصل الزمني منذ آخر تحديث.

بالنسبة للحسابات متعددة المناطق، فإن الحد الأدنى لقيمة KوT هو 100,000 عملية كتابة أو 300 ثانية. تحدد هذه القيمة الحد الأدنى من RPO للبيانات عند استخدام bounded staleness.

لمزيد من المعلومات حول الاختلافات بين مستويات التناسق، راجع مستويات التناسق في Azure Cosmos DB.

مناطق قراءة متعددة مع منطقة كتابة واحدة

إذا كان الحل يتطلب وقت تشغيل مستمرا أثناء انقطاع المنطقة، يمكنك تكوين Azure Cosmos DB لنسخ بياناتك عبر مناطق متعددة، مع معالجة عمليات الكتابة بواسطة منطقتك الأساسية. يمكنك تكوين تطبيقاتك بشكل اختياري للاتصال بمناطق قراءة محددة، والتي يمكن أن تساعد على تحسين أدائها. إذا كان هناك انقطاع في المنطقة، يمكن للحساب الاستمرار في العمل من مناطق سليمة.

رسم تخطيطي يوضح حساب Azure Cosmos DB. المنطقة أ هي منطقة الكتابة والقراءة، والمنطقة B هي منطقة قراءة. يقوم تطبيق في المنطقة أ بإجراء عمليات القراءة والكتابة مقابل حساب Azure Cosmos DB في المنطقة أ. يقوم تطبيق في المنطقة ب بإجراء القراءة مقابل الحساب في المنطقة ب، ولكنه يكتب مقابل المنطقة أ. داخليا، Azure Cosmos DB نسخ التغييرات بين المناطق.

تجاوز الفشل بين المناطق

يمكنك تكوين Azure Cosmos DB SDK مع قائمة ذات أولوية من مناطق القراءة. يربط SDK التطبيق الخاص بك بأول منطقة متوفرة في القائمة. خلال انقطاع منطقة القراءة، يكتشف SDK انقطاع المنطقة من خلال رموز الاستجابة الخلفية، ويصنفه كغير متاح، ويوجه العمليات المستقبلية إلى المنطقة المتاحة التالية في قائمة التفضيلات. تأكد من تعيين قائمة المناطق المفضلة بشكل صحيح ومواءمتها مع متطلبات العمل وزمن الانتقال. للحصول على إرشادات تفصيلية، انظر Troubleshoot Azure Cosmos DB SDK availability.

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

  • إذا أصبحت منطقة الكتابة غير متوفرة، تصبح منطقة أخرى منطقة الكتابة.
  • إذا أصبحت منطقة القراءة غير متوفرة، فلا يمكن لتلك المنطقة تقديم طلبات القراءة ويتم استخدام مناطق أخرى لعمليات القراءة بدلا من ذلك.

يوفر Azure Cosmos DB أنواعا متعددة من تجاوز الفشل:

  • تجاوز الفشل التلقائي لكل قسم (PPAF): داخليا، ينشر Azure Cosmos DB بياناتك عبر أقسام مادية متعددة. إذا حدثت مشكلة في البنية الأساسية التي تدعم قسما، فقد لا تتأثر أقسام أخرى. تمكن PPAF حسابات منطقة الكتابة الواحدة من الفشل تلقائيا عبر الأقسام الفردية إلى منطقة ثانوية مع الحفاظ على أقسام سليمة في المنطقة الأساسية. يمكن أن يساعد PPAF في تقليل وقت التعطل وتمكين استرداد أسرع أثناء فشل المنطقة الجزئي. لمزيد من المعلومات، راجع كيفية إلحاق Per-Partition تجاوز الفشل التلقائي (PPAF) واعتماده Azure Cosmos DB.

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

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

    يحمل تجاوز الفشل القسري لمنطقة الكتابة إمكانية فقدان البيانات لأي عمليات كتابة غير مبسطة.

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

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

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

    تتطلب هذه العملية أن تكون المناطق سليمة، لذلك لا يمكن استخدامها أثناء انقطاع المنطقة.

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

    إذا Microsoft بتشغيل تجاوز الفشل المدار بواسطة الخدمة لمنطقة الكتابة للحساب، فقد تفقد أي عمليات كتابة غير مبسطة.

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

المتطلبات

دعم المنطقة: يمكنك تكوين أي منطقة Azure كمنطقة قراءة لحساب Azure Cosmos DB الخاص بك.

Cost

تؤدي إضافة منطقة قراءة إضافية إلى حساب Azure Cosmos DB إلى زيادة التكاليف الحالية لكل منطقة. لمزيد من المعلومات، راجع تسعير Azure Cosmos DB.

تكوين مناطق قراءة متعددة

تخطيط القدرات وإدارتها

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

السلوك عندما تكون جميع المناطق صحية

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB مع مناطق قراءة متعددة، وتكون جميع المناطق قيد التشغيل.

  • عملية عبر المناطق: يقوم تطبيقك بتكوين المنطقة التي يجب أن تتلقى عمليات القراءة. يمكنك تكوين التطبيق الخاص بك مع قائمة ذات أولوية من المناطق، أو لاستبعاد بعض المناطق. لمزيد من المعلومات حول كيفية عمل تحديد المنطقة، راجع تشخيص واستكشاف أخطاء توفر Azure Cosmos DB SDKs في البيئات متعددة المناطق وإصلاحها.

    يتم توجيه جميع عمليات الكتابة إلى منطقة الكتابة في حسابك.

  • النسخ المتماثل للبيانات عبر المناطق: تحدث جميع عمليات الكتابة في المنطقة الأساسية لحسابك. يتم نسخ عمليات الكتابة إلى مناطق القراءة الأخرى استنادا إلى مستوى التناسق المكون للحساب. للحصول على معلومات حول الحد الأقصى لتأخر النسخ المتماثل، راجع فقدان البيانات المحتمل أثناء انقطاع المنطقة.

السلوك أثناء فشل منطقة القراءة

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB مع مناطق قراءة متعددة، وهناك انقطاع في إحدى مناطق القراءة للحساب.

مهم

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

  • الكشف والاستجابة: تعتمد مسؤولية الكشف عن الانقطاع والاستجابة على نوع تجاوز الفشل الذي يستخدمه حسابك.

    • PPAF: لا تنطبق PPAF عادة على انقطاع منطقة القراءة. ومع ذلك، بالنسبة للحسابات ذات التناسق القوي ومنطقتين فقط، يؤدي فقدان منطقة القراءة إلى تقليل الحساب إلى منطقة واحدة، والتي لا يمكنها الحفاظ على الحصة الديناميكية. في هذا السيناريو، يمكن تنشيط PPAF للحفاظ على التوفر عن طريق تحويل الأقسام المتأثرة إلى المنطقة الصحية.

    • تجاوز الفشل القسري: أنت مسؤول عن تنفيذ تجاوز الفشل القسري. للحصول على خطوات مفصلة، راجع تنفيذ تجاوز الفشل القسري لحساب Azure Cosmos DB الخاص بك.

      إذا لم تقم بإجراء تجاوز فشل، يعتمد سلوك حسابك على مستوى التناسق الخاص به:

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

      • تناسق Bounded staleness: يعتمد تناسق Bounded staleness على الحفاظ على حد ثبات محدد بين المناطق. إذا تجاوز طول انقطاع المنطقة الحد، فلن يتمكن النظام من الحفاظ على التناسق بين عمليات الكتابة. إذا لم تقم بإجراء تجاوز فشل، يفقد الحساب توفر الكتابة حتى استعادة الخدمة.

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

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

  • فقدان البيانات المتوقع: لا يؤدي الانقطاع في منطقة القراءة إلى فقدان البيانات. يستمر Azure Cosmos DB في احترام ضمانات تناسق القراءة.

  • وقت التعطل المتوقع: يعتمد مقدار وقت التعطل الذي تمر به حسابك على نوع تجاوز الفشل الذي يستخدمه حسابك.

    • PPAF: عند تمكين PPAF، يكتشف النظام تلقائيا ويسترد من الفشل، عادة في غضون 3 دقائق، دون أي تدخل يدوي.

    • تجاوز الفشل القسري: يعتمد وقت التعطل على:

      • كم من الوقت يستغرق اكتشاف الانقطاع وبدء تجاوز الفشل.

      • كم من الوقت يستغرق تجاوز الفشل، وهو عادة بضع ثوان.

        التحذير

        لا تقم بإجراء أي عمليات تكوين (مستوى التحكم) على المنطقة المتأثرة أثناء سيناريوهات الانقطاع، لأنها تؤدي إلى عدم تناسق الحساب وتأخير الاسترداد. بعض أمثلة عمليات طائرة التحكم التي يجب تجنبها تشمل:

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

  • اعاده توزيع: بالنسبة لتجاوز الفشل القسري أو تجاوز الفشل المدار بواسطة الخدمة، يتم قطع اتصال المنطقة المتأثرة ووضع علامة عليها على أنها غير متصلة.

    لا توجد تغييرات مطلوبة في التعليمات البرمجية للتطبيق لمعالجة انقطاعات منطقة القراءة. تعيد Azure Cosmos DB SDKs توجيه عمليات القراءة إلى المنطقة المتوفرة التالية في قائمة المنطقة المفضلة. إذا لم تتوفر أي من المناطق في قائمة المناطق المفضلة، فإن عمليات القراءة تعود تلقائيا إلى منطقة الكتابة الحالية للحساب كما تم تكوينها في الخدمة.

    ملحوظة

    إذا كنت تستخدم نقاط نهاية خاصة مع حساب Azure Cosmos DB، فتأكد من توجيه DNS الخاص بشكل صحيح بعد عملية المنطقة دون اتصال. للحصول على إرشادات مفصلة، راجع اعتبارات الفشل لنقاط النهاية الخاصة.

السلوك أثناء فشل منطقة الكتابة

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB مع مناطق قراءة متعددة، وهناك انقطاع في منطقة الكتابة للحساب.

  • الكشف والاستجابة: تعتمد مسؤولية الكشف عن الانقطاع والاستجابة على نوع تجاوز الفشل الذي يستخدمه حسابك.

    • PPAF: يكشف Microsoft تلقائيا عن الانقطاع ويبدأ تجاوز الفشل لبعض الأقسام، إذا كان ذلك مناسبا. لا يحتاج تطبيقك إلى اتخاذ أي إجراء.

    • تجاوز الفشل القسري: أنت مسؤول عن تنفيذ تجاوز الفشل القسري. للحصول على خطوات مفصلة، راجع تنفيذ تجاوز الفشل القسري لحساب Azure Cosmos DB الخاص بك.

      إذا لم تقم بإجراء تجاوز فشل، يفقد الحساب توفر الكتابة حتى استعادة الخدمة.

      إذا كان هناك انقطاع في منطقة الكتابة في حسابك، فتجنب إجراء عملية تغيير في منطقة الكتابة . لا تنجح تغييرات منطقة الكتابة إذا كان هناك انقطاع في منطقة المصدر أو الوجهة. والسبب هو أن إجراء تغيير المنطقة يتضمن فحص التناسق الذي يتطلب الاتصال بين المناطق.

    • تجاوز الفشل المدار بواسطة الخدمة: يكشف Microsoft تلقائيا عن الانقطاع ويبدأ تجاوز فشل حسابك. لا يحتاج تطبيقك إلى اتخاذ أي إجراء.

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

  • فقدان البيانات المتوقع: إذا قمت بتكوين حسابك بتناسق قوي، فلن يحدث أي فقدان للبيانات. وإلا، قد يتم فقدان أي عمليات كتابة غير مبسطة بعد اكتمال تجاوز الفشل. للحصول على معلومات حول الحد الأقصى لفقدان البيانات المتوقع أثناء انقطاع المنطقة، راجع فقدان البيانات المحتمل أثناء انقطاع المنطقة.

  • وقت التعطل المتوقع: يعتمد مقدار وقت التعطل الذي تمر به حسابك على نوع تجاوز الفشل الذي يستخدمه حسابك.

    • PPAF: عند تمكين PPAF، توقع انقطاعا قصيرا، والذي عادة ما يكون حوالي 3 دقائق.

    • تجاوز الفشل القسري: يعتمد وقت التعطل على:

      • كم من الوقت يستغرق اكتشاف الانقطاع وبدء تجاوز الفشل.
      • كم من الوقت يستغرق تجاوز الفشل، وهو عادة بضع ثوان.

    التحذير

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

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

    • PPAF: يفشل Azure Cosmos DB تلقائيا عبر القسم غير السليم إلى منطقة صحية.

    • تجاوز الفشل القسري: عند إجراء تجاوز فشل إجباري، تتغير منطقة الكتابة في حسابك إلى المنطقة التي تحددها.

    ملحوظة

    إذا كنت تستخدم نقاط نهاية خاصة مع حساب Azure Cosmos DB، فتأكد من توجيه DNS الخاص بشكل صحيح بعد عملية المنطقة دون اتصال. للحصول على إرشادات مفصلة، راجع اعتبارات الفشل لنقاط النهاية الخاصة.

    • تجاوز الفشل المدار بواسطة الخدمة: Azure Cosmos DB ترقية إحدى المناطق الثانوية للحساب تلقائيا لتكون منطقة الكتابة الأساسية الجديدة. يحدث تجاوز الفشل لمنطقة أخرى بترتيب أولوية المنطقة التي تحددها.

انتعاش المنطقة

يجب على Microsoft إعادة المنطقة إلى الإنترنت. عندما تتعافى منطقة بعد انقطاع التيار الكهربائي، Microsoft تلقائيا بجلب المنطقة عبر الإنترنت. ومع ذلك، قد تستغرق هذه العملية عدة أيام.

مهم

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

بعد أن تكون المنطقة متصلة بالإنترنت، تختلف الإجراءات التي تتخذها اعتمادا على ما إذا كان الانقطاع في منطقة قراءة أو منطقة كتابة.

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

  • بعد انقطاع منطقة الكتابة: عندما تعود المنطقة المتأثرة إلى الاتصال بالإنترنت، تظهر المنطقة على أنها "متصلة" في مدخل Azure، وتصبح متاحة كمنطقة قراءة. في هذه المرحلة، من الآمن تغيير منطقة الكتابة مرة أخرى إلى المنطقة المستردة.

    مهم

    لن تتم ترقية المنطقة المستردة مرة أخرى كمنطقة الكتابة تلقائيا بمجرد استردادها. تقع على عاتقك مسؤولية التغيير مرة أخرى إلى المنطقة المستردة كمنطقة كتابة، بمجرد أن تصبح آمنة للقيام بذلك.

    لا يوجد فقدان للبيانات أو التوفر قبل أو أثناء أو بعد تغيير منطقة الكتابة. لا يزال تطبيقك متوفرا بشكل كبير.

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

اختبار حالات فشل المنطقة

قد لا يتعامل تطبيقك مع عمليات تجاوز الفشل في المنطقة بشكل صحيح، حتى إذا كان حساب Azure Cosmos DB الخاص بك متوفرا بشكل كبير. لاختبار قابلية الوصول العالية من طرف إلى طرف لتطبيقك كجزء من اختبار التطبيق أو تدريبات التعافي من الكوارث (DR)، قم بتعطيل تجاوز الفشل المدار بواسطة الخدمة للحساب مؤقتا. استدعاء تجاوز الفشل القسري باستخدام PowerShell أو Azure CLI أو مدخل Azure، ثم مراقبة التطبيق الخاص بك. بعد إكمال الاختبار، يمكنك إرجاع الموارد مرة أخرى إلى المنطقة الأساسية بمجرد عودة المنطقة إلى الاتصال بالإنترنت تلقائيا، ثم استعادة تجاوز الفشل المدار بواسطة الخدمة للحساب. إذا لم تعود المنطقة إلى الإنترنت في غضون يوم أو يومين، فافتح حالة دعم لطلب المساعدة.

إذا كان حسابك يستخدم PPAF، يمكنك محاكاة تجاوز فشل القسم. لمزيد من المعلومات، راجع اختبار إعداد PPAF (محاكاة الخطأ).

مناطق كتابة متعددة

يمكنك تكوين Azure Cosmos DB لقبول عمليات الكتابة في مناطق متعددة. يمكن أن يوفر هذا التكوين مرونة عالية جدا للانقطاعات في المنطقة. كما أنه مفيد لتقليل زمن انتقال الكتابة في التطبيقات الموزعة جغرافيا.

رسم تخطيطي يوضح حساب Azure Cosmos DB. المنطقة (أ) والمنطقة (ب) هما منطقتا الكتابة والقراءة. يقوم تطبيق في المنطقة أ بإجراء عمليات القراءة والكتابة مقابل حساب Azure Cosmos DB في المنطقة أ. يقوم تطبيق في المنطقة ب بإجراء عمليات القراءة والكتابة مقابل حساب Azure Cosmos DB في المنطقة ب. داخليا، Azure Cosmos DB نسخ التغييرات بشكل غير متزامن بين المناطق.

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

من المهم مراعاة تصميم تطبيقك وكيفية عمله مع مناطق كتابة متعددة. راجع أفضل الممارسات للكتابات متعددة المناطق.

المتطلبات

دعم المنطقة: يمكنك تكوين أي منطقة Azure كمنطقة قراءة أو كتابة لحساب Azure Cosmos DB الخاص بك.

Cost

تؤدي إضافة منطقة كتابة إضافية إلى حساب Azure Cosmos DB إلى زيادة التكاليف الحالية لكل منطقة. لمزيد من المعلومات، راجع تسعير Azure Cosmos DB.

تكوين مناطق كتابة متعددة

يمكنك تكوين مناطق كتابة متعددة على حسابك عند إنشاء الحساب أو في أي وقت بعد إنشاء الحساب. لمزيد من المعلومات، راجع تكوين مناطق كتابة متعددة.

لاستخدام مناطق كتابة متعددة بشكل فعال، يجب أيضا تكوين تطبيقك بشكل مناسب. راجع تكوين عمليات الكتابة متعددة المناطق في التطبيقات التي تستخدم Azure Cosmos DB.

تخطيط القدرات وإدارتها

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

السلوك عندما تكون جميع المناطق صحية

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB مع مناطق كتابة متعددة، وتكون جميع المناطق قيد التشغيل.

السلوك أثناء فشل المنطقة

يصف هذا القسم ما يجب توقعه عند تكوين حساب Azure Cosmos DB مع مناطق كتابة متعددة، وهناك انقطاع في إحدى مناطق القراءة أو الكتابة في الحساب.

  • الكشف والاستجابة: يكتشف التطبيق الخاص بك فقدان المنطقة. توفر Azure Cosmos DB SDKs قدرات تحديد المنطقة التلقائية التي توجه عمليات القراءة والكتابة إلى مناطق سليمة.
  • الطلبات النشطة: قد يتم إنهاء أي طلبات نشطة وتحتاج إلى إعادة المحاولة من قبل العميل بعد اكتمال تجاوز الفشل. إذا تعامل عملاؤك مع الأخطاء العابرة بشكل مناسب عن طريق إعادة المحاولة بعد فترة قصيرة من الزمن ، فإنهم عادة ما يتجنبون تأثيرا كبيرا.

  • فقدان البيانات المتوقع: قد تصبح البيانات المحدثة مؤخرا غير متوفرة في مناطق أخرى. للحصول على معلومات حول الحد الأقصى لفقدان البيانات المتوقع أثناء انقطاع المنطقة، راجع فقدان البيانات المحتمل أثناء انقطاع المنطقة. في حالة تعرض المنطقة المتأثرة لفقدان دائم للبيانات، قد تفقد بيانات غير مبسطة.

  • وقت التعطل المتوقع: لا يوجد وقت تعطل متوقع في تكوينات الكتابة المتعددة، شريطة تكوين SDKs بشكل صحيح باستخدام ApplicationRegions أو PreferredRegions.

    نصيحة

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

  • اعاده توزيع: تكتشف Azure Cosmos DB SDKs تلقائيا أن المنطقة غير صحية وإعادة توجيه عمليات القراءة والكتابة إلى المنطقة المتوفرة التالية في قائمة المنطقة المفضلة. لا توجد تغييرات مطلوبة في التعليمات البرمجية للتطبيق الخاص بك.

    نصيحة

    إذا كان التطبيق الخاص بك أمام الواجهة الأمامية لـ Azure أو Traffic Manager، فإن هذه الخدمات تكتشف أيضا التدهور الإقليمي وتوجه حركة المرور إلى منطقة صحية.

انتعاش المنطقة

عندما تعود المنطقة المتأثرة إلى الاتصال بالإنترنت، تظهر المنطقة على أنها "متصلة" في مدخل Azure، وتصبح متاحة مرة أخرى.

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

اختبار حالات فشل المنطقة

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

النسخ الاحتياطي والاستعادة

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

يمكن أن يحدث فقدان البيانات بسبب عمليات الحذف العرضية أو المشاكل الأخرى في التطبيق الخاص بك التي تسبب تلف البيانات. عند استخدام حساب منطقة واحدة، قد يحدث فقدان البيانات أيضا بسبب كارثة غير قابلة للاسترداد في منطقة Azure Cosmos DB. لمساعدتك على الحماية من فقدان البيانات، يوفر Azure Cosmos DB مجموعة من قدرات النسخ الاحتياطي والاستعادة. يمكنك تكوين النسخ الاحتياطية والاحتفاظ استنادا إلى متطلبات الاسترداد ومتطلبات التكلفة. لمزيد من المعلومات، راجع النسخ الاحتياطي عبر الإنترنت واستعادة البيانات عند الطلب في Azure Cosmos DB.

المرونة في صيانة الخدمة

يدير Azure Cosmos DB بشفافية جميع تفاصيل عقد الحوسبة الفردية، ويقوم تلقائيا بإجراء التصحيح وأنواع أخرى من الصيانة المخطط لها. تنطبق اتفاقيات مستوى الخدمة Azure Cosmos DB للتوفر وزمن الانتقال من خلال جميع عمليات الصيانة التلقائية التي يقوم بها النظام.

اتفاقية مستوى الخدمة

تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.

يوفر Azure Cosmos DB اتفاقيات مستوى الخدمة لمجموعة من التكوينات وخصائص الخدمة، بما في ذلك التوفر وزمن الانتقال ومعدل النقل والاتساق.

تختلف اتفاقيات مستوى الخدمة للتوفر اعتمادا على ما إذا كنت تستخدم أي من إمكانات المنتج التالية:

  • معدل النقل المقدم
  • حساب منطقة واحدة مع دعم منطقة التوفر (تكرار المنطقة)
  • الحسابات التي تستخدم مناطق قراءة متعددة
  • الحسابات التي تستخدم مناطق كتابة متعددة (طبقة الأعمال الحرجة)