記錄一次線上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配置