منع أخطاء تحديد المعدل ل Azure Cosmos DB لعمليات Apache Cassandra

ينطبق على: كاساندرا

يتم تسوية تكلفة جميع عمليات قاعدة البيانات بواسطة Azure Cosmos DB ويتم التعبير عنها بواسطة وحدات الطلب (RU). وحدة الطلب هي عملة أداء تستخلص موارد النظام مثل CPU وIOPS والذاكرة المطلوبة لتنفيذ عمليات قاعدة البيانات التي يدعمها Azure Cosmos DB.

قد تفشل Azure Cosmos DB لعمليات Apache Cassandra مع أخطاء تحديد المعدل (OverloadedException/429) إذا تجاوزت حد معدل نقل الجدول (RUs). يمكن معالجة هذا من جانب العميل كما هو موضح هنا. إذا تعذر تنفيذ نهج إعادة محاولة العميل للتعامل مع الفشل بسبب خطأ تحديد المعدل، فيمكننا الاستفادة من ميزة إعادة المحاولة من جانب الخادم (SSR) حيث ستتمت إعادة محاولة العمليات التي تتجاوز معدل النقل بالجدول تلقائياً بعد فترة تأخير قصيرة. هذا إعداد على مستوى الحساب وينطبق على جميع المساحات والجداول الرئيسية في الحساب.

استخدام مدخل Microsoft Azure

  1. قم بتسجيل الدخول إلى بوابة Azure.

  2. انتقل إلى Azure Cosmos DB لحساب Apache Cassandra.

  3. انتقل إلى جزء Features أسفل قسم Settings.

  4. حدد Server-Side Retry.

  5. انقر فوق Enable لتمكين هذه الميزة لجميع المجموعات في حسابك.

لقطة شاشة لميزة إعادة المحاولة من جانب الخادم ل Azure Cosmos DB ل Apache Cassandra

استخدام Azure CLI

  1. تحقق مما إذا كانت ميزة SSR (إعادة المحاولة من جانب الخادم) ممكّناً بالفعل لحسابك:

    az cosmosdb show --name accountname --resource-group resourcegroupname
    
  2. Enable SSR لجميع الجداول في حساب قاعدة البيانات الخاص بك. قد يستغرق دخول هذا التغيير حيز التنفيذ ما يصل إلى 15 دقيقة.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra DisableRateLimitingResponses
    
  3. سيقوم الأمر التالي Disable بإعادة المحاولة من جانب الخادم لجميع الجداول في حساب قاعدة البيانات عن طريق إزالة DisableRateLimitingResponses من قائمة الإمكانات. قد يستغرق دخول هذا التغيير حيز التنفيذ ما يصل إلى 15 دقيقة.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra
    

الأسئلة الشائعة

كيف تتمت إعادة محاولة الطلبات؟

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

متى تكون ميزة SSR (إعادة المحاولة من جانب الخادم) أكثر فائدة؟

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

اقترح إعدادات من جانب العميل؟

بعد تمكين SSR، يجب أن يزيد تطبيق العميل مهلة القراءة بعد إعداد إعادة محاولة الخادم لمدة 60 ثانية. نوصي بأن تكون الـ 90 ثانية في الجانب الأكثر أماناً.

نموذج التعليمات البرمجية Driver3

SocketOptions socketOptions = new SocketOptions()
	.setReadTimeoutMillis(90000); 

نموذج التعليمات البرمجية Driver4

ProgrammaticDriverConfigLoaderBuilder configBuilder = DriverConfigLoader.programmaticBuilder()
	.withDuration(DefaultDriverOption.REQUEST_TIMEOUT, Duration.ofSeconds(90)); 

كيف يمكنني مراقبة تأثيرات إعادة المحاولة من جانب الخادم؟

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

يمكنك البحث عن إدخالات السجل التي تحتوي على estimatedDelayFromRateLimitingInMilliseconds في سجلات موارد Azure Cosmos DB.

هل ستؤثر إعادة المحاولة من جانب الخادم على مستوى التناسق الخاص بي؟

لا تؤثر إعادة المحاولة من جانب الخادم على مستويات التناسق. تتمت إعادة محاولة الطلبات من جانب الخادم إذا كانت محدودة السعر (خطأ 429).

هل تؤثر إعادة المحاولة من جانب الخادم على أي نوع من الأخطاء قد يتلقاها عميلي؟

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

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

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

راجع المقالات التالية للتعرف على معدل النقل في Azure Cosmos DB: