精华 ClickHouse基于复制的故障恢复测试
发布于 2 个月前 作者 jackpgao 318 次浏览 来自 分享

数据恢复

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

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

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

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

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

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

测试环境

  • 如图,基于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

  • 关于故障恢复:

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

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

回到顶部