ClickHouse基于复制的故障恢复测试
2017-12-18 本文已影响719人
JackpGao
在之前的博客中，我们讨论了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，这个手动挡的感觉怎么样？
