【列存引擎内核】ReplicatedMergeTree

单节点 MergeTree 无 HA；ReplicatedMergeTree 通过协调服务（ClickHouse Keeper 或 ZooKeeper）同步 Part 级 元数据与文件，实现多副本。24.x 文档推荐 Keeper（Raft），路径语义与 ZK 兼容。

本环境未部署双节点集群——下文给可复现步骤，不伪造 system.replicas 输出。

一、架构

flowchart TB
  CH1[Replica 1] --> K[Keeper / ZK]
  CH2[Replica 2] --> K
  INS[Insert] --> CH1
  CH1 --> LOG[Log entry]
  LOG --> CH2
  CH2 --> FETCH[Fetch Part 文件]

二、ZooKeeper / Keeper 路径

官方 ReplicatedMergeTree 约定（示意）：

/table_path/replicas/<replica_name>/log
/table_path/replicas/<replica_name>/queue
/table_path/replicas/<replica_name>/parts
/table_path/leader_election
/table_path/quorum

Log entry 类型：GET_PART、MERGE_PARTS、DROP_PART、MUTATE_PART 等。

sequenceDiagram
  participant C as Client
  participant R1 as Replica 1
  participant K as Keeper
  participant R2 as Replica 2
  C->>R1: INSERT
  R1->>R1: 写本地 Part
  R1->>K: 追加 log entry
  K->>R2: 通知 queue
  R2->>R1: Fetch Part 或本地执行 MERGE entry
  R2->>R2: 激活 Part

三、写入与同步

1. 客户端 insert 到任一副本（或 Distributed）。
2. 副本写本地 Part + 写 log。
3. 其他副本消费 queue，fetch Part 或本地执行 merge entry。
4. quorum 设置控制 insert 确认副本数。

四、Recovery

副本 lag：system.replicas 的 absolute_delay、queue_size；system.replication_queue 看待执行任务。

断网恢复：落后副本按 queue 补 Part；严重不一致需 SYSTEM RESTORE REPLICA 等运维操作（以官方文档为准）。

五、实验步骤（读者自测）

1. 部署 3 节点 Keeper（或单节点 Keeper 测试）。
2. 两节点 ReplicatedMergeTree 同 zookeeper_path 与不同 replica_name。
3. 停一节点网络，insert 持续；恢复后观察 system.replication_queue 消化。
4. 记录本机输出，本文不编造。

SELECT database, table, is_leader, absolute_delay, queue_size
FROM system.replicas;

六、与 Distributed 关系

ReplicatedMergeTree 是 本地表引擎；Distributed 是 分片路由（第 9 篇）。生产常：每 shard 内 ReplicatedMergeTree + 上层 Distributed。

七、学术谱系：副本新鲜度 · Keeper · 非 HTAP

分布式 OLAP 的经典问题是：副本何时可见同一 Part 集合（新鲜度）与 协调服务故障域。本篇机制（ReplicatedMergeTree log + Keeper）回答工程路径；不展开 TiDB/TiFlash 式 HTAP（见 db-frontier/12）。

7.1 争论与开放问题

• 争论：强同步副本（写路径等齐）vs 异步 fetch（ingest 优先）。CH 默认偏后者；金融级「读己之写跨副本」需上层约束。
• 开放问题：Keeper 抖动时 merge/fetch 队列如何自动降载？可检验：注入 Keeper 延迟后 replication_queue 长度与 insert 限流（入口：CH Replication；对照 HTAP 新鲜度档位仅作阅读，不并入本系列）。

八、小结

副本一致性在 Part + log 层；Keeper 是协调中枢；lag 从 system.replicas 查。

上一篇：索引与跳数索引

下一篇：系列索引 — Distributed 规划中

参考资料

核心论文 / 坐标

1. Stonebraker et al., C-Store, VLDB 2005（RS 只读存储直觉；A 级）——本篇将其扩展到多副本 Part。
2. db-frontier/12 HTAP（新鲜度档位对照；不并入本系列正文结论）。

规范 / 源码 / 文档

3. ClickHouse Documentation, ReplicatedMergeTree、ClickHouse Keeper（A 级）。
4. ClickHouse Source, StorageReplicatedMergeTree.cpp（A 级）。

ReplicatedMergeTree 日志

协调服务（ZooKeeper 或 ClickHouse Keeper）路径示例（官方 ReplicatedMergeTree）：

/table_path/replicas/replica_name/log          # 待执行 entry
/table_path/replicas/replica_name/queue        # 本地队列
/table_path/replicas/replica_name/parts         # 已确认 part
/table_path/leader_election                    # leader 选举

Log entry 类型：GET_PART、MERGE_PARTS、DROP_PART、MUTATE_PART 等。

副本一致性

Insert 在 leader（或任意副本写 log）；follower 拉 part 文件或本地 merge。system.replicas、system.replication_queue 诊断 lag。

Keeper

24.x 推荐 ClickHouse Keeper 替代 ZooKeeper（Raft）；路径语义兼容，运维组件不同。

Merge selector

SimpleMergeSelector / TTLMergeSelector 等根据 Part 大小、年龄、分区挑选 merge 任务；目标减少 Part 数且控制写放大。

ReplacingMergeTree

replace 版本列默认 is_deleted 或显式 version；merge 同排序键保留 version 最大。查询仍可能见重复行，除非 FINAL 或应用层去重。

CollapsingMergeTree

Sign 列 +1/-1 表示插入与撤销；merge 折叠成 net 行。适合变更流而非物理 DELETE。

Mutation 路径

ALTER TABLE UPDATE/DELETE → MutationCommands 队列 → 后台读 Part 重写新 Part → 原子替换。堆积时 system.mutations 可见；与 merge 争用 BackgroundSchedulePool。