副本与 ReplicatedMergeTree

      ClickHouse Keeper 集群 (Raft, 建议 3 或 5 节点)
      ┌─────────┐   ┌─────────┐   ┌─────────┐
      │ keeper1 │───│ keeper2 │───│ keeper3 │   ← 存的是"协调元数据"
      └─────────┘   └─────────┘   └─────────┘
           ▲              ▲              ▲
           │ 读写 znode    │              │
      ┌────┴────┐    ┌────┴────┐    ┌────┴────┐
      │ ch-rep1 │    │ ch-rep2 │    │ ch-rep3 │   ← 真正存数据的副本
      └─────────┘    └─────────┘    └─────────┘

CREATE TABLE events_local ON CLUSTER my_cluster
(
    event_time  DateTime,
    user_id     UInt64,
    event_type  LowCardinality(String),
    page        String,
    country     LowCardinality(String),
    device      LowCardinality(String),
    duration_ms UInt32
)
ENGINE = ReplicatedMergeTree(
    '/clickhouse/tables/{shard}/default/events',   -- ZK 路径，{shard} 由 macros 替换
    '{replica}'                                    -- 副本名，{replica} 由 macros 替换
)
PARTITION BY toYYYYMM(event_time)
ORDER BY (country, event_type, event_time);

<!-- ch-node1 的 /etc/clickhouse-server/config.d/macros.xml -->
<clickhouse>
    <macros>
        <shard>01</shard>
        <replica>ch-node1</replica>
    </macros>
</clickhouse>
 
<!-- ch-node2（同一分片的另一个副本） -->
<clickhouse>
    <macros>
        <shard>01</shard>          <!-- 同分片：shard 相同 -->
        <replica>ch-node2</replica> <!-- 不同副本：replica 不同 -->
    </macros>
</clickhouse>
 
<!-- ch-node3（第二个分片） -->
<clickhouse>
    <macros>
        <shard>02</shard>          <!-- 不同分片：shard 不同 -->
        <replica>ch-node3</replica>
    </macros>
</clickhouse>

建表语句里的宏         ch-node1          ch-node2          ch-node3
──────────────────────────────────────────────────────────────
{shard}              01                01                02
{replica}            ch-node1          ch-node2          ch-node3
 
→ node1、node2 的 ZK 路径都是 /clickhouse/tables/01/... → 互为副本
→ node3 的 ZK 路径是 /clickhouse/tables/02/...          → 属于另一个分片

写入节点（假设是 Leader 副本）            跟随副本（Follower）
        │                                       │
   INSERT 一批数据                         监听 Keeper 路径
        │                                       │
   1. 本地落盘生成 part                        │
   2. 在 Keeper 的 /log 下挂一条记录           │
      "新增 part xxx，校验和=yyy"    ──────►  3. 收到通知，拉取该 part
                                             4. 校验和一致 → 本地写入
                                             5. 在 Keeper 的 /blocks 登记"我也有这个 part"

-- 验证复制是否到位：在两台节点分别执行，数字应一致
SELECT
    hostName() AS node,
    count()    AS parts,
    sum(rows)  AS rows
FROM system.parts
WHERE table = 'events_local' AND active;

正常：   shard1 = {node1(leader), node2}   读/写都能选 node1 或 node2
宕机：   shard1 = {node1 ✗, node2}          写转到 node2，读自动避开 node1
恢复：   node1 重启 → 监听 Keeper 日志 → 把宕机期间 node2 产生的 part 拉回来

Keeper 节点数    容忍宕机数    是否推荐
   1               0           ✗ 单点，挂了全停
   3               1           ✓ 最小可用
   5               2           ✓✓ 生产推荐

-- 查看表的复制队列是否堆积（waiting > 0 表示有 part 还没复制出去）
SELECT database, table,
       queue_size, inserts_in_queue, mutations_in_queue
FROM system.replicas
WHERE table = 'events_local';
 
-- 手动触发与某个副本的全量同步（数据严重错位时）
SYSTEM RESTORE REPLICA events_local;
 
-- 重新拉取 Keeper 中的表结构（结构冲突时）
SYSTEM SYNC REPLICA events_local;
 
-- 查看副本延迟（相对 Leader 落后多少）
SELECT database, table, is_leader, absolute_delay
FROM system.replicas;