Embedded ClickHouse Keeper vs External ZooKeeper for Operational Isolation on Node Failure

Selecting coordination for a ClickHouse cluster involves choosing between embedded ClickHouse Keeper and an external ZooKeeper ensemble. The decision is framed by a concrete operational constraint: maintaining metadata availability and DDL progress when individual ClickHouse nodes fail under load.

ClickHouse Keeper runs in-process with the server since v21.8 and GA v22.3, sharing CPU, memory and disk I/O with query workloads. External ZooKeeper isolates coordination traffic to a separate JVM and network hop but adds operational surface. Both require a majority quorum for DDL and replica metadata changes, while reads and writes on existing parts can continue without quorum.

The unresolved behavior concerns rolling migration from ZooKeeper to Keeper in an existing cluster. Documentation describes dual-write migration but does not specify failure semantics if the migration is interrupted during a quorum change.

What is the documented split-brain or metadata divergence risk if a ZooKeeper-to-Keeper migration is interrupted mid-quorum-change? Which ClickHouse version pairs are officially supported for the migration tooling? Does co-location of Keeper with query workloads increase the likelihood of false leader elections under resource pressure compared to isolated ZooKeeper?