ReplicatedMergeTree —— ClickHouse 实现数据复制的核心表引擎

ReplicatedMergeTree 是 ClickHouse 实现数据复制的核心表引擎，它在经典的 MergeTree 基础上增加了多副本自动同步能力，是构建高可用、可扩展 OLAP 集群的基石。

本篇将深入详解 ReplicatedMergeTree 的工作原理、配置方法、使用场景和最佳实践，帮助你真正掌握 ClickHouse 的复制能力。

---

🔁 一、什么是 ReplicatedMergeTree？

✅ 定义

ReplicatedMergeTree 是一种支持数据复制的表引擎，它确保同一份数据在多个节点（副本）上保持一致。当某个节点宕机时，其他副本仍可提供读写服务，从而实现 高可用性（HA） 和 读扩展性。

🔄 它是 MergeTree 的复制增强版，专为生产环境设计。

---

🏗️ 二、核心架构与依赖组件

ReplicatedMergeTree 的复制能力依赖两个关键组件：

组件	作用
ZooKeeper 或 ClickHouse Keeper	协调副本间的数据同步、选举、元数据管理
Replication Log（复制日志）	每个副本在 ZooKeeper 中维护一个操作队列

⚠️ 注意：数据本身不经过 ZooKeeper 传输，ZooKeeper 只负责“协调指令”，实际数据通过 P2P 方式在副本间传输。

---

🔗 三、复制工作原理（图解 + 详解）

1. 数据写入流程（以写入 Replica 1 为例）

客户端
   │
   ↓
[Replica 1] → 写入本地 part（数据片段）
   │
   ↓
向 ZooKeeper 提交“写入任务”（包含数据路径、校验和）
   │
   ↓
[Replica 2,3...] 监听 ZooKeeper，发现新任务
   │
   ↓
其他副本从 Replica 1 下载数据（P2P）
   │
   ↓
所有副本本地合并数据，保持一致

2. 后台合并（Merge）同步

• 每个副本独立执行 Merge（合并小 parts）
• 合并任务也通过 ZooKeeper 协调，确保所有副本执行相同操作

3. 故障恢复

• 若某副本宕机，重启后会从 ZooKeeper 获取缺失的操作日志
• 自动补同步，无需人工干预

---

🛠️ 四、配置 ReplicatedMergeTree（实战）

1. 前提条件

• 至少 2 个 ClickHouse 节点
• 一个 ZooKeeper 集群（或 ClickHouse Keeper）

✅ 推荐：3 节点 ZooKeeper 或启用 ClickHouse Keeper

---

2. 配置 ZooKeeper（在 config.xml 中）

<zookeeper>
    <node>
        <host>zk1</host>
        <port>2181</port>
    </node>
    <node>
        <host>zk2</host>
        <port>2181</port>
    </node>
    <node>
        <host>zk3</host>
        <port>2181</port>
    </node>
</zookeeper>

---

3. 创建 ReplicatedMergeTree 表

CREATE TABLE user_log_replicated (
    user_id UInt32,
    event_date Date,
    action String,
    duration UInt32
) ENGINE = ReplicatedMergeTree(
    '/clickhouse/tables/{shard}/user_log',  -- ZooKeeper 路径
    '{replica}'                            -- 副本标识（自动替换）
)
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

🔍 参数详解：

参数	说明
/clickhouse/tables/{shard}/user_log	在 ZooKeeper 中的路径，必须唯一
{shard}	分片标识（如 shard1），由集群配置决定
{replica}	副本标识（如 replica1），通常用主机名或 IP

✅ 不同表必须使用不同的 ZooKeeper 路径，否则会冲突！

---

4. 在多副本集群中使用（配合 Distributed 表）

-- 创建分布式表，用于跨分片查询
CREATE TABLE user_log_all ON CLUSTER 'your_cluster'
ENGINE = Distributed(
    'your_cluster',
    'default',
    'user_log_replicated',
    rand()
);

✅ 查询 user_log_all 会自动路由到所有分片的副本，支持负载均衡。

---

🔄 五、ReplicatedMergeTree 的变种

ReplicatedMergeTree 有多个“复制版”变种，适用于不同场景：

引擎	用途
ReplicatedMergeTree	通用复制表
ReplicatedReplacingMergeTree	自动去重 + 复制
ReplicatedSummingMergeTree	数值求和 + 复制
ReplicatedAggregatingMergeTree	预聚合 + 复制
ReplicatedCollapsingMergeTree	状态折叠 + 复制

✅ 使用方式完全相同，只需替换引擎名。

---

📊 六、监控复制状态

1. 查看副本信息

SELECT 
    table,
    is_leader,
    is_readonly,
    is_session_expired,
    queue_size,
    absolute_delay
FROM system.replicas 
WHERE database = 'default' AND table = 'user_log_replicated';

关键字段说明：

字段	含义
is_leader	是否为当前协调者（Leader）
queue_size	待同步任务数（积压）
absolute_delay	同步延迟（秒）
total_replicas / active_replicas	总副本数 / 活跃副本数

✅ 健康状态：queue_size = 0, absolute_delay ≈ 0, active_replicas = total_replicas

---

2. 查看复制队列

SELECT * FROM system.replication_queue 
WHERE database = 'default' AND table = 'user_log_replicated';

可查看正在执行或失败的复制任务。

---

⚠️ 七、常见问题与注意事项

问题	原因	解决方案
数据未同步	ZooKeeper 连接失败、网络不通	检查 ZooKeeper 状态和网络
queue_size 持续增长	写入压力大、磁盘慢	优化写入批次、升级硬件
is_readonly = 1	ZooKeeper 断开	检查网络、ZooKeeper 是否可用
重复数据	使用了 POPULATE	禁止使用 POPULATE
合并失败	数据损坏、磁盘满	检查日志，清理空间

---

✅ 八、最佳实践建议

项目	推荐做法
副本数量	2 副本（平衡成本与可用性）
ZooKeeper	3 节点集群，独立部署
ClickHouse Keeper	新集群推荐使用
表命名	本地表加 _replicated，分布式表加 _all
写入	可写任意副本，或通过负载均衡
查询	使用 Distributed 表自动路由
备份	备份一个副本即可（数据相同）
升级	滚动升级，先升级非 Leader 副本

---

🎯 九、总结：ReplicatedMergeTree 的核心价值

能力	说明
🛡️ 高可用	任意副本宕机，服务不中断
📈 读扩展	查询可分发到多个副本
🔁 自动同步	数据变更自动传播
🔄 故障恢复	重启后自动补同步
🧩 与分片结合	构建完整的分布式 OLAP 集群

🎯 ReplicatedMergeTree 是 ClickHouse 生产环境的“标配”
没有复制，就没有真正的高可用。