Three requests that turned out to have answers

Three of my requests ended in a comment rather than a pull request. Each taught me where to look.

• #84884, cluster() and clusterAllReplicas() should skip unavailable nodes. A down node fails the whole query (ALL_CONNECTION_TRIES_FAILED), exactly when you want to read system.server_settings from every node. Eight minutes after I opened it, den-crane asked whether I had tried SETTINGS skip_unavailable_shards = 1. I had not; I closed it within the hour. The setting defaults to 0, and 26.3 added max_skip_unavailable_shards_num and max_skip_unavailable_shards_ratio as a guard against silently answering from half a cluster. See compare settings across a cluster.
• #87468, enable_analyzer is logged as allow_experimental_analyzer. In system.query_log the Settings map showed the old name. novikd closed it with one line: enable_analyzer is an alias and the original name is what gets recorded. The alias is visible in system.settings.alias_for. Practical consequence: filter the query log on the old name.
• #92005, ttl_only_move_parts. I assumed a counterpart to ttl_only_drop_parts was missing. UnamedRus answered the next morning: TTL moves already work on whole parts, so there is nothing to opt into. A delete TTL is row-based, a move TTL is not. See tiered storage and TTL: delete only matching rows.

The cheap lesson: grep system.settings and system.merge_tree_settings with LIKE '%skip%' before filing. The less cheap one: if three of my requests hit features or behaviors that already exist, discoverability is itself a usability problem.