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 نتيجة مبنية من الشظايا المتبقية. لذلك فهذا هو الوضع الأكثر تساهلًا ويجب استخدامه بحذر.