ClickHouse和Zookeeper

背景

ClickHose使用Zookeeper的地方还是比较多的，像副本leader的选举、副本表写入的同步，以及整个集群、表的meta信息都是通过Zookeeper来实现的。由于本身Zookeeper的机制尽量保证最终一致性（CP），写操作都是通过leader节点来完成的，本身存在单点性能问题。随着集群规模的增大，Zookeeper的压力也会越来越大，CH是支持多ZK集群的，一般来说说我们不需要这么做，根据官方给的经验：单zk集群完全可以支持300台机器的CH集群规模。当然，如果必要，可以给ZK配置高性能的磁盘，比如：ssd盘。依赖那么多，必然会有出问题的时候，今天给大家分享下最近遇到的一些问题。

问题1：:Exception: Existing table metadata in ZooKeeper differs in sorting key expression. Stored in ZooKeeper:

详情如下：

问题2：Replica xxx-01-01 already exists..

详情如下：

问题3：Cannot allocate block number in ZooKeeper: Coordination::Exception: No node, path:

详情如下：

问题4：Cannot allocate block number in ZooKeeper: Coordination::Exception: No node, path:

此类问题一般都是一些不合规操作或者环境稳定性问题导致的，比如：

1、ZK相关的错误

ZK的配置或者状态异常（裂变等），或者压根就是配置错误。

2、环境引起的

比如：删除表之后，默认CH不会立即删除ZK中的meta信息，是无一致性保证的，如果异步删的时候，网络不稳定或者zk服务不正常，就会删除失败，导致表的meta信息在zk中残留。

对于ZK的问题，做相关的恢复操作即可，如果由于zk压力大引起，建议给zk所在的机器配置一块好一些的磁盘。如果你们系统对数据的完整性要求不是那么高，也可以对zk做如下配置，开启写缓存的操作。

forceSync=no

此选项一般来说是不建议开启的，请慎重选择。

问题修复总结

ZK信息错乱，不太好修复。如果此时你还能连上CH，那么可以将数据进行备份到新表。然后修复ZK中的表META信息，数据备份后就可以直接删除表，然后重新建。参考命令如下：

--备份数据

drop table t_xx;

SYSTEM DROP REPLICA 'cluster01-01-01' FROM ZKPATH '/clickhouse/tables/01-01/ t_xx ';

create table t_xx...

如果连CH都启动不起来了，那么需要先将CH恢复，让能正常启动。