Zookeeper一次故障处理

记录一次线上Zookeeper故障

---

2018.02.06

部门引入了ClickHouse作为数据分析仓库，并且使用了复制表ReplicatedMergeTree，两个集群复制表的数据同步依赖Zookeeper，上线前就对Zookeeper的性能产生过顾虑，但是线上运行一段时间后，未发现异常。直到最近几周，故障频现，本文主要记录故障处理过程以及故障处理的一些思考和坑。

第一次故障

故障定位

第一次故障十分突然，Kafka、Mesos和Yarn都收到了影响。因为对Zookeeper的信任，因此排查耗费了一些时间。通过重启Kafka，发现连接Zookeeper超时才定位到ZK出现问题。

故障处理

查看zookeeper.log，日志中大量如下报错

2018-01-27 06:39:43,728 [myid:5] - WARN  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running

重启Zookeeper但是无法恢复，日志中依然是上述not running报错

根据这个报错baidu、google，没有找到解决办法，看到有人猜测有脏数据写入，更改数据存储目录可以解决。当时对Zookeeper原理不大清楚，以及对元数据不够重视，听信了这个办法。成功启动Zookeeper，但是所有的Metadata都丢失了，这之后的填坑操作就不一一赘述了。

第二次故障

故障定位

同事调研Zookeeper监控方案是，在某个节点上使用

echo mntr | nc localhost 2181

返回信息

This ZooKeeper instance is not currently serving requests

于是确定这个节点异常，并且查看zookeeper.log，依旧是大量not running报错且持续了若干天，但是重启无法恢复

故障处理

这个节点无法恢复，因为集群有3个节点，所以暂时搁置，保留2个节点的运行状态，需要终极解决办法

第三次故障

故障定位

Kafka受到影响。因为之前的经验，所以直接查看Zookeeper状态，发现Zookeeper异常，线上和前几次故障一致

故障处理

整个集群三个节点都无法启动，且没有找到解决方法，夜已经深了。为了保证元数据，最后采用standalone模式先撑过一段时间，standalone模式成功启动。

第四次故障

故障原因

因为standalone模式没有HA，工作日需要重新恢复到高可用模式，这期间找到一篇文章Sudden crash of all nodes in the cluster，大概猜测到了之前集群故障的原因

Zookeeper的快照文件snapshot特别大，之前故障的时候观察过，一个snapshot就6G，并且几分钟就生成一个snapshot。集群模式下，follower节点需要获取leader节点的snapshot，在initLimit时间内没有同步完成，因此无法启动Zookeeper。线上配置如下

tickTime=2000
initLimit=10
syncLimit=5

而snapshot单个文件过大的问题猜测是ClickHouse导致的，因为ClickHouse数据同步依赖Zookeeper，每一个数据Part都需要做checksum等操作。通过Zookeeper提供的SnapshotFormatter获取snapshot内容

java -cp zookeeper-3.4.9.jar:lib/* org.apache.zookeeper.server.SnapshotFormatter /data0/zookeeper/data1/version-2/snapshot.ee008e8774

发现大量的Clickhouse Znode，因此验证之前的猜想。

在恢复HA模式的过程中，更新zoo.conf，调整syncLimit（这是之前一个理解错误，应该调整initLimit），先重启myid为1的节点（之前的standalone节点），再重启myid为2以及myid为3的节点。全部重启后Zookeeper可以运行在集群模式下，但是发现丢了ClickHouse的元数据，ClickHouse集群复制表无法正常工作。

数据丢失原因猜测：

一开始myid=1的节点（standalone）节点为leader，向myid=3的节点发送snapshot。snapshot未发送完成，集群重新选主，myid=3的节点成为了leader，myid=1的节点同步myid=3的节点数据，导致数据丢失

snapshot传输未完成以及集群重新选主的原因暂时不明

故障处理

使用一个变更之前的snapshot，起一个standalone模式的Zookeeper，是这个Zookeeper恢复至变更之前的状态。并且将ClickHouse依赖的Zookeeper迁移至这个单点的Zookeeper。曲线救国，暂时完成了ClickHouse业务的Zookeeper独立以及老Zookeeper集群的高可用。

后续

参考ClickHouse官网提供的Zookeeper配置