إعدادات الجلسة لـ skip_unavailable_shards_*

هذه الإعدادات متاحة في system.settings، وقد أُنشئت تلقائيًا من الشفرة المصدرية.

يُمكّن أو يعطّل تخطي الشظايا غير المتاحة بصمت.

يتحكم المعلَم skip_unavailable_shards_mode في سلوك هذا الإعداد.

القيم الممكنة:

• 1 — التخطي مُمكَّن.

  إذا كانت إحدى الشظايا غير متاحة، يعيد ClickHouse نتيجةً استنادًا إلى بيانات جزئية ولا يُبلغ عن مشكلات توافر العُقد.

• 0 — التخطي مُعطَّل.

  إذا كانت إحدى الشظايا غير متاحة، يطرح ClickHouse استثناء.

يتحكم هذا الإعداد في الاستثناءات الواردة من شظية بعيدة التي يتم تجاهلها بصمت عند تمكين skip_unavailable_shards. لا يكون لهذا الإعداد أي تأثير عندما تكون قيمة skip_unavailable_shards = 0.

القيم الممكنة:

• unavailable — يتم تجاهل الأخطاء المرتبطة بالاتصال فقط. وتُعد الشظية غير متاحة عندما يتعذر على ClickHouse الاتصال بأي من replicas الخاصة به، أو عندما يتعذر تحليل hostname الخاص بـ replica عبر DNS.

• unavailable_or_table_missing — بالإضافة إلى unavailable، يتم تجاهل الأخطاء الناتجة عن عدم وجود table أو database على الشظية. ويكون ذلك مفيدًا أثناء إنشاء table أو حذفها على مستوى cluster. هذه هي القيمة الافتراضية، وهي تتوافق مع السلوك السابق لـ skip_unavailable_shards، الذي كان يعامل أيضًا الشظية التي لا يوجد جدولها على أنها غير متاحة.

• unavailable_or_exception_before_processing — بالإضافة إلى unavailable، يتم تجاهل أي استثناء يتم استلامه من شظية قبل أن يعيد أي data block إلى initiator. أما الاستثناء الذي يصل بعد أن تكون الشظية قد أعادت بعض البيانات بالفعل، فيُعاد إطلاقه دائمًا. لاحظ أن التحقق من عبارة "قبل أن يعيد أي بيانات" يتم عند initiator: فقد تقوم الشظية التي تنفذ عملية حسابية حاجزة (مثل aggregation أو sort أو LIMIT BY) بمعالجة rows ثم تفشل قبل إصدار أي block، وفي هذه الحالة يتم تجاهل عملها الجزئي بصمت ويُرجع query نتيجة مبنية من الشظايا المتبقية. لذلك فهذا هو الوضع الأكثر تساهلًا ويجب استخدامه بحذر.