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

发表于 | 分类于 |

数据恢复

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

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

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

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

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

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

测试环境

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

预期假设

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

测试过程

Node3’上的情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 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’’，观察复制情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# 之前只有分布式表，没有本地表
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

最终数据量

1
2
3
4
5
6
7
8
9
10
# 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

  • 关于故障恢复：

    • 如果是Node3宕机，并且可恢复，重启后无需关注，CH会自动同步
    • 如果Node3宕机，且不可恢复，需要更换新的机器，新增节点，需要注意：
      • ZK路径毫无疑问需要一致，分片名称务必不能一致，因为此时ZK里已经记录了先前Node3节点的路径、副本名称，如果按照Node3上的表结构一模一样创建表，会报错
      • 此时要么删了ZK里Node3原来的信息（风险），要么把副本名称改一下

  • 故障恢复的过程中，的确存在带宽

  • 至此，ClickHouse的复制机制测试完毕，各位老司机，相比HDFS，这个手动挡的感觉怎么样？

热评文章