paramètres de session skip_unavailable_shards_*

Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du code source.

Active ou désactive l’ignorance silencieuse des shards indisponibles.

Le comportement de ce réglage est contrôlé par le paramètre skip_unavailable_shards_mode.

Valeurs possibles :

• 1 — ignorance activée.

  Si un shard est indisponible, ClickHouse renvoie un résultat basé sur des données partielles et ne signale pas les problèmes de disponibilité des nœuds.

• 0 — ignorance désactivée.

  Si un shard est indisponible, ClickHouse lève une exception.

Contrôle quelles exceptions provenant d’un shard distant sont ignorées silencieusement lorsque skip_unavailable_shards est activé. Ce paramètre n’a aucun effet lorsque skip_unavailable_shards = 0.

Valeurs possibles :

• unavailable — Seules les erreurs liées à la connexion sont ignorées. Un shard est considéré comme indisponible lorsque ClickHouse ne peut se connecter à aucune de ses répliques, ou lorsque le nom d’hôte d’une réplique ne peut pas être résolu via DNS.

• unavailable_or_table_missing — En plus de unavailable, les erreurs dues à l’absence d’une table ou d’une base de données sur le shard sont ignorées. Cela est utile lorsqu’une table est en cours de création ou de suppression à l’échelle d’un cluster. Il s’agit de la valeur par défaut, qui correspond au comportement historique de skip_unavailable_shards, lequel considérait également comme indisponible un shard dont la table n’existe pas.

• unavailable_or_exception_before_processing — En plus de unavailable, toute exception reçue d’un shard avant qu’il n’ait renvoyé le moindre bloc de données à l’initiateur est ignorée. Une exception qui arrive après que le shard a déjà renvoyé des données est toujours relancée. Notez que la condition « avant qu’il n’ait renvoyé des données » est vérifiée côté initiateur : un shard qui effectue un calcul bloquant (par exemple une agrégation, un tri ou LIMIT BY) peut traiter des lignes et échouer avant d’émettre le moindre bloc, auquel cas son travail partiel est silencieusement abandonné et la requête renvoie un résultat construit à partir des shards restants. Il s’agit donc du mode le plus permissif et il doit être utilisé avec prudence.