zookeeper運維問題總結
1、一臺zk節點失聯後，重啟一直無法加入zk集群中，導致無法對外提供服務
2、zk的log和快照占大量空間
3、客戶端連接有失敗有成功
4、zk客戶端偶爾會有失敗連接
5、報錯：smaller server identifier,so dropping
以上問題生產環境中經常會遇到
1. zk無法加入zk集群
現象: 使用zkCli.sh無法連接成功該zk節點
日誌: 首先想到的是將該節點restart, 但問題依舊, 故查看zk的log, 有大量的如下日誌
2018-07-18 17:31:12,015 - INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 1 (n.leader), 77309411648 (n.zxid), 1 (n.round), LOOKING (n.state), 1 (n.sid), LOOKING (my state) 2018-07-18 17:31:12,016 - INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 3 (n.leader), 73014444480 (n.zxid), 831 (n.round), LEADING (n.state), 3 (n.sid), LOOKING (my state) 2018-07-18 17:31:12,017 - INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 3 (n.leader), 77309411648 (n.zxid), 832 (n.round), FOLLOWING (n.state), 2 (n.sid), LOOKING (my state) 2018-07-18 17:31:15,219 - INFO [QuorumPeer:/0.0.0.0:2181:FastLeaderElection@697] - Notification time out: 6400
解決辦法：
這個是在3.3.4版本中的一個bug，在新版本中3.5已經修復了，建議使用最新版本
如果你使用的是這個版本，那你只能通過重啟leader來解決了
2. zk的log和快照占大量空間
現象：zk的datadir下的version-2下有很多快照，日誌目錄下有大日誌文件（單個文件太大），有些東西是沒有用的，所以建議定期清除
解決辦法：在zk的配置文件中添加自動清理日誌和快照的開關autopurge.purgeInterval=1,當然也可以中過個年autopurge.snapRetainCount來設置需要保留的snapshot文件個數，默認是3個。
3. 客戶端連接有失敗有成功
現象：客戶端的連接有的可以連，有的連接失敗
Too many connection from 127.0.0.1 -max is 60解決辦法：
更改zk配置的連接數maxClientCnxns 加大這個值，默認是60，不建議設置的太大，防止DDOS×××
4. zk客戶端偶爾會有失敗連接
現象：有時客戶端偶爾會連不上zk
原因：
這種情況比較復雜，跟代碼及邏輯有關系了，以及當前的業務量有關系，比如zk處理大量的短連接請求時，SYN QUEUE的accept queue有時候被打滿，這就尷尬了，直接導致連接失敗。
詳細可以查看這篇文章
https://blog.csdn.net/varyall/article/details/79681562
解決辦法：
syn隊列的大小是系統用來限制網絡的高並發的，具體參數如下：
如果太小了，會導致這種問題，需要按量提高，不要太高了。
生產環境中最終的解決辦法是最好降低和zk的短連接數量，這樣就基本不會出這種問題。
5. 報錯：smaller server identifier,so dropping
現象：使用客戶端連接沒法連上，查看zk日誌，發現很多報錯報錯：smaller server identifier,so dropping
解決辦法：
按zk的myid的大小從小到大一次重啟zk服務器，首先保證有問題的zk不重啟。
分析原因：zk是需要集群中所有機器兩兩建立連接的, 其中配置中的3555端口是用來進行選舉時機器直接建立通訊的端口, 大id的server才會去連接小id的server，避免連接浪費.如果是最後重啟myid最小的實例,該實例將不能加入到集群中, 因為不能和其他集群建立連接
zookeeper運維問題總結