ClickHouse基于复制的故障恢复测试

在之前的博客中，我们讨论了ClickHouse的最佳架构，其中考虑了两点

扩展性，即集群机器越多，性能越高，集群性能=∑单机性能

可靠性，通过使用复制机制，来抵抗单机宕机、机房宕机风险

其中第二点，依赖ClickHouse的复制引擎，即ReplicatedMergeTree引擎
在ZK的基础上，共享同一个ZK路径的节点，会相互同步数据

本测试主要用来做灾难恢复测试，即集群中某个分片对应的某2个节点挂了一个，新增一个节点，存量数据同步情况和效率

为了保证测试有价值，找了一个15亿行数据的表，数据文件22GB

测试环境

Snip20171218_9.png

如图，基于ZK构建了两组集群
- 两侧看做2个集群，数据各占1/3，使用分布式引擎做横向扩展
- 其中Node1和Node1'、Node2和Node2'、Node3和Node3'使用复制引擎，相互做备份
- 现在假设Node3出现了宕机，新增一个节点，观察数据同步的过程是否符合预期

预期假设

复制会把网卡打满
数据最终一致

测试过程

Node3'上的情况

# 22GB数据文件

root@10.xx.xx.x:/data1/clickhouse/data/ck_test  # du -sh * 
22G     dagger
4.0K    dagger_all


# 15亿数据
:) select count(*)/100000000 from dagger;

SELECT count(*) / 100000000
FROM dagger

┌─divide(count(), 100000000)─┐
│                15.02450289 │
└────────────────────────────┘

1 rows in set. Elapsed: 0.170 sec. Processed 1.50 billion rows, 1.50 GB (8.85 billion rows/s., 8.85 GB/s.)

新增节点Node3''，观察复制情况

# 之前只有分布式表，没有本地表
root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
4.0K    dagger_all

# 新建本地表后，数据文件不断增加，同步开始
root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
471M    dagger
4.0K    dagger_all

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
565M    dagger
4.0K    dagger_all

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
3.8G    dagger
4.0K    dagger_all
root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
4.0G    dagger
4.0K    dagger_all

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # date
Mon Dec 18 10:44:43 CST 2017

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
5.7G    dagger
4.0K    dagger_all

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
16G     dagger
4.0K    dagger_all

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # date
Mon Dec 18 10:46:30 CST 2017
root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # date 
Mon Dec 18 10:46:42 CST 2017

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
17G     dagger
4.0K    dagger_all

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # date    
Mon Dec 18 10:47:36 CST 2017

root@10.xx.xx.xx:/data1/clickhouse/data/ck_test  # du -sh *
22G     dagger
4.0K    dagger_all

最终数据量

# 15亿，与其他节点保持一致

:) select count(*)/100000000 from dagger;

SELECT count(*) / 100000000
FROM dagger 

┌─divide(count(), 100000000)─┐
│                15.02450289 │
└────────────────────────────┘

复制过程带宽和日志

Snip20171218_5

Snip20171218_6

Snip20171218_8

结论

CH的复制过程，就是查看自己所在的副本是否有其他节点的数据片，这个过程就是查看ZK里的元数据，如果没有，就开始从其他节点搬迁数据，搬迁速度等于最大带宽
因此，同一份数据，日常至少有2份即可，如果其中一份挂掉，新建一个表，把另一份及时通过过来就好（当然日常保留多份更好）
数据一致性，依赖ZK元数据，即复制引擎在做数据快写入的时候，记录的数据快信息数据

Snip20171218_11

Snip20171218_13.png

关于故障恢复：
- 如果是Node3宕机，并且可恢复，重启后无需关注，CH会自动同步
- 如果Node3宕机，且不可恢复，需要更换新的机器，新增节点，需要注意：
  - ZK路径毫无疑问需要一致，分片名称务必不能一致，因为此时ZK里已经记录了先前Node3节点的路径、副本名称，如果按照Node3上的表结构一模一样创建表，会报错
  - 此时要么删了ZK里Node3原来的信息（风险），要么把副本名称改一下
故障恢复的过程中，的确存在带宽
至此，ClickHouse的复制机制测试完毕，各位老司机，相比HDFS，这个手动挡的感觉怎么样？