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.
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 deunavailable, 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 deskip_unavailable_shards, lequel considérait également comme indisponible un shard dont la table n’existe pas. -
unavailable_or_exception_before_processing— En plus deunavailable, 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 ouLIMIT 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.