skip_unavailable_shards_* session settings

​

skip_unavailable_shards

• 1 — skipping enabled. If a shard is unavailable, ClickHouse returns a result based on partial data and does not report node availability issues. On a read, if every shard was skipped before returning any data there is no partial data left to return, so the query throws ALL_CONNECTION_TRIES_FAILED instead of returning an empty result. This check covers reads only; INSERT has its own handling of a fully unavailable destination cluster.
• 0 — skipping disabled. If a shard is unavailable, ClickHouse throws an exception.

​

skip_unavailable_shards_mode

• unavailable — Only connection-related errors are ignored. A shard is considered unavailable when ClickHouse cannot connect to any of its replicas, or when a replica’s hostname cannot be resolved through DNS.
• unavailable_or_table_missing — In addition to unavailable, errors caused by a missing table or database on the shard are ignored. This is useful while a table is being created or dropped across a cluster. This is the default and matches the historical behavior of skip_unavailable_shards, which also treated a shard whose table does not exist as unavailable.
• unavailable_or_exception_before_processing — In addition to unavailable, any exception received from a shard before it returned any data block to the initiator is ignored. An exception that arrives after the shard already returned some data is always rethrown. Note that “before it returned any data” is checked at the initiator: a shard that performs a blocking computation (for example an aggregation, sort, or LIMIT BY) may process rows and fail before emitting any block, in which case its partial work is silently discarded and the query returns a result built from the remaining shards. This is therefore the most permissive mode and should be used with care.