skip_unavailable_shards_* session settings

These settings are available in system.settings and are autogenerated from source.

skip_unavailable_shards

Enables or disables silently skipping of unavailable shards.

The behavior of this setting is controlled by the skip_unavailable_shards_mode parameter.

Possible values:

• 1 — skipping enabled.

  If a shard is unavailable, ClickHouse returns a result based on partial data and does not report node availability issues.

• 0 — skipping disabled.

  If a shard is unavailable, ClickHouse throws an exception.

skip_unavailable_shards_mode

Controls which exceptions from a remote shard are silently ignored when skip_unavailable_shards is enabled. The setting has no effect when skip_unavailable_shards = 0.

Possible values:

• 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.