ClickHouse ReplicatedMergeTree能否检测双节点添加同名异类型列的冲突？

核心结论 #

总有一条ALTER语句会执行失败，冲突会在Zookeeper注册阶段被检测到，不会进入后续异步执行环节。

具体执行逻辑 #

ReplicatedMergeTree的分布式ALTER操作完全依赖Zookeeper做集群状态协调：

• 每个ALTER任务提交时，首先会在Zookeeper对应表的路径下注册操作元数据，并校验当前集群的表结构状态。
• 当节点A和B同时提交两条冲突的ADD COLUMN操作时：
  1. 先完成ZK注册的操作（比如节点A的Added1 UInt32）会被集群所有节点同步执行，更新表的全局元数据。
  2. 后提交的节点B的操作在注册ZK时，会立即检测到表元数据中已存在同名Added1列，且类型（String）与现有列类型（UInt32）冲突，直接返回执行失败，不会进入后续异步执行流程。

冲突检测的关键 #

ClickHouse在ALTER操作的ZK注册阶段就会做严格的元数据兼容性校验，对于这类同名但类型/定义不一致的ADD COLUMN操作，属于明确的冲突场景，ZK的分布式锁和元数据同步机制会直接阻止第二个操作完成注册，从而保证集群表结构的一致性。

涉及的操作语句 #

节点A执行：

ALTER TABLE alter_test ADD COLUMN Added1 UInt32 FIRST;

节点B执行：

ALTER TABLE alter_test ADD COLUMN Added1 String FIRST;

内容的提问来源于stack exchange，提问作者djbobo