ClickHouseCluster 的副本和分片，如何安全地扩缩容 KeeperCluster 的 quorum，以及在扩缩容操作进行过程中应关注哪些状态条件。
ClickHouseCluster 始终需要一个 Keeper，并通过必填的 spec.keeperClusterRef 字段引用它——无论集群规模如何，operator 都会通过它来协调集群。若要让每个分片运行多个副本，数据还必须存储在 ReplicatedMergeTree 表中，因为只有复制机制才能让第二个副本提供相同的行。副本扩缩容
spec.replicas 用于设置每个分片中的副本数量。每个副本都在各自的 StatefulSet 中运行，其名称为 <cluster>-clickhouse-<shard>-<replica>，因此一个配置为 shards: 2 和 replicas: 3 的集群会运行六个 StatefulSet。
直接就地增减副本数：
分片扩缩容
spec.shards 用于设置分片数量。每新增一个分片，都会增加一整套按副本划分的 StatefulSets；此外，operator 还会为每个分片创建一个 PodDisruptionBudget，以确保某个分片发生中断时，不会影响其他分片的计算。
Distributed 表或显式路由方案决定一行数据会落到哪个分片上，因此新增一个分片时，新写入的数据就有了新的落点，而无需改动现有分片中已存储的行。
自动 schema 同步
spec.settings.enableDatabaseSync 为 true (默认值) 时，operator 会在拓扑变化时保持 schema 同步：
- 扩容时 — 一旦至少有两个副本就绪，operator 就会将 database 定义复制到新创建的副本，使新副本加入后与集群中其余副本拥有相同的
Replicated和集成 database。 - 缩容时 — 在某个副本消失之前，operator 会使用
SYSTEM DROP DATABASE REPLICA从每个Replicateddatabase 中删除该副本的注册信息，这样缩容后的集群就不会再等待一个已不存在的Replicateddatabase 副本。
Replicated databases 和集成 database 引擎。它不会迁移表数据——行数据保存在 ReplicatedMergeTree 表中，并通过 Keeper 独立于此 schema 同步机制进行复制。当只有一个就绪副本时，没有可复制的目标，因此 operator 会跳过此步骤，并记录没有可用目标。
将 enableDatabaseSync: false 设为关闭此行为，例如当 schema 传播由外部工具负责时。此后，operator 会在 SchemaInSync 状态条件上报告 SchemaSyncDisabled 原因。
需关注的状态条件
当
ClusterSizeAligned 报告 UpToDate、SchemaInSync 报告 ReplicasInSync，且 Ready 报告 AllShardsReady 时，一次扩缩容操作即完成。
Keeper 的扩缩容
KeeperCluster 运行的是 RAFT quorum，因此 operator 只有在集群处于稳定状态时，才会一次只变更一个副本的成员资格。
这样可以保护 quorum：2F+1 的集群可容忍 F 个成员宕机，因此 3 节点集群即使缺少 1 个成员仍可继续运行，5 节点集群即使缺少 2 个成员也是如此。
maxUnavailable: replicas/2，以在自愿性中断期间维持 quorum。
ScaleAllowed 状态条件会报告当前 quorum 是否可以变更成员：
请按单步方式对 Keeper 进行扩缩容，并在每次变更之间等待
ScaleAllowed 恢复为 ReadyToScale。一次性跳过多个成员并不会绕过逐个执行 reconcile 的机制——Operator 仍会按每步一个成员的方式逐步调整 quorum。