ClickHouse高可用集群
和一些在使用clickhouse的同学聊了下，有不少中小型公司使用的还是单机版，这点还是出乎意料；可能真的是因为clickhouse秒天秒地的性能，加上数据量不大，数据恢复成本不高，才出此策略；
入正题：今天尝试搭建了一个2*2的clickhouse集群，两个分片，每个分片有两个副本，共四个节点，逻辑拓扑图如下
| host | shard | replica |
|---|---|---|
| hadoop2 | 01 | 01 |
| hadoop5 | 01 | 02 |
| hadoop6 | 02 | 01 |
| hadoop7 | 02 | 02 |
1.安装clickhouse-server
在所有节点安装clickhouse-server,参考clickhouse install on centos
2.修改配置config.xml
涉及三部分remote_servers,zookeeper,macros,所有的节点的remote_servers,zookeeper是一样的，不同的是macros，每个节点根据自己的角色修改shard和replica的值；下面给出hadoop2这个节点的配置
true
hadoop2
9666
hadoop5
9666
true
hadoop6
9666
hadoop7
9666
hadoop1
2181
hadoop2
2181
hadoop3
2181
hadoop4
2181
hadoop5
2181
01
01
启动所有的clickhouse-server
service clickhouse-server start
3.建表
在每个节点创建t_s2_r2，不需要手动替换shard和replica，建表的时候会根据shard和replica数据自行在zookeeper中注册
CREATE TABLE t_s2_r2\
(\
dt Date,\
path String \
)\
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/t_s2_r2','{replica}',dt, dt, 8192)
创建分布式表t_s2_r2_all，这个表在任何一个节点创建都行，t_s2_r2_all就像一个视图，指向所有的分片，数据真正的存储在每个节点的t_s2_r2表
CREATE TABLE t_s2_r2_all AS t_s2_r2 ENGINE = Distributed(perftest_2shards_2replicas, default, t_s2_r2, rand())
插入数据
insert into t_s2_r2_all values('2019-07-21','path1')
insert into t_s2_r2_all values('2019-07-22','path1')
insert into t_s2_r2_all values('2019-07-23','path1')
insert into t_s2_r2_all values('2019-07-23','path1')
查看数据
hadoop7 :) select * from t_s2_r2_all
SELECT *
FROM t_s2_r2_all
┌─────────dt─┬─path──┐
│ 2019-07-21 │ path1 │
│ 2019-07-22 │ path1 │
│ 2019-07-24 │ path1 │
└────────────┴───────┘
┌─────────dt─┬─path──┐
│ 2019-07-23 │ path1 │
└────────────┴───────┘
4 rows in set. Elapsed: 0.009 sec.
查看每个节点表t_s2_r2数据
hadoop2 :) select * from t_s2_r2
SELECT *
FROM t_s2_r2
┌─────────dt─┬─path──┐
│ 2019-07-23 │ path1 │
└────────────┴───────┘
hadoop5 :) select * from t_s2_r2
SELECT *
FROM t_s2_r2
┌─────────dt─┬─path──┐
│ 2019-07-23 │ path1 │
└────────────┴───────┘
1 rows in set. Elapsed: 0.007 sec.
hadoop6 :) select * from t_s2_r2
SELECT *
FROM t_s2_r2
┌─────────dt─┬─path──┐
│ 2019-07-21 │ path1 │
│ 2019-07-22 │ path1 │
│ 2019-07-24 │ path1 │
└────────────┴───────┘
3 rows in set. Elapsed: 0.002 sec.
hadoop7 :) select * from t_s2_r2
SELECT *
FROM t_s2_r2
┌─────────dt─┬─path──┐
│ 2019-07-21 │ path1 │
│ 2019-07-22 │ path1 │
│ 2019-07-24 │ path1 │
└────────────┴───────┘
3 rows in set. Elapsed: 0.002 sec.
可以看到hadoop2和hadoop5数据是一致的，hadoop6和hadoop7数据是一致的，现在测试下高可用，干掉hadoop2节点
service clickhouse-server stop
t_s2_r2_all数据依旧可查，因为shard01还有一个存活副本hadoop5
hadoop7 :) select * from t_s2_r2_all
SELECT *
FROM t_s2_r2_all
┌─────────dt─┬─path──┐
│ 2019-07-21 │ path1 │
│ 2019-07-22 │ path1 │
│ 2019-07-24 │ path1 │
└────────────┴───────┘
┌─────────dt─┬─path──┐
│ 2019-07-23 │ path1 │
└────────────┴───────┘
4 rows in set. Elapsed: 0.008 sec.
现在依然可以插入数据
insert into t_s2_r2_all values('2019-07-29','path2')
这条数据落在了shard01上
hadoop5 :) select * from t_s2_r2
SELECT *
FROM t_s2_r2
┌─────────dt─┬─path──┐
│ 2019-07-29 │ path2 │
└────────────┴───────┘
┌─────────dt─┬─path──┐
│ 2019-07-23 │ path1 │
└────────────┴───────┘
2 rows in set. Elapsed: 0.002 sec.
现在再启动hadoop2节点上的clickhouse-server，刚才插入的数据，会自动同步到hadoop2的t_s2_r2中
hadoop2 :) select * from t_s2_r2
SELECT *
FROM t_s2_r2
┌─────────dt─┬─path──┐
│ 2019-07-29 │ path2 │
└────────────┴───────┘
┌─────────dt─┬─path──┐
│ 2019-07-23 │ path1 │
└────────────┴───────┘
2 rows in set. Elapsed: 0.003 sec.
当hadoop2和hadoop5上的clickhouse-server同时被干掉时，那t_s2_r2_all就不可用了，这个应该很好理解，这里就不再测了
End