- 實際工作中用到Zookeeper叢集的地方很多, 也碰到過各種各樣的問題, 在這裡作個收集整理, 後續會一直補充;
- 其中很多問題的原因, 解決方案都是google而來, 這裡隻是作次搬運工;
- 其實很多問題都跟配置有關, 隻怪自己沒好好讀文檔;
-
問題清單:
1. 一台 zk 節點重新開機後始終無法加入到叢集中, 無法對外提供服務
2. zk的log和snapshot占用大量空間
3. 某台用戶端上有的程序可以連接配接到zk, 有的無法連接配接
4. 一台zk伺服器無法對外提供服務,報錯"Have smaller server identifier, so dropping
the connection."
5. zk用戶端偶爾無法成功連接配接到zk server
一台 zk 節點重新開機後始終無法加入到叢集中, 無法對外提供服務
- 現象: 使用zkCli.sh無法連接配接成功該zk節點
- 日志: 首先想到的是将該節點restart, 但問題依舊, 故檢視zk的log, 有大量的如下日志
2017-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)
2017-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)
2017-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)
2017-07-18 17:31:15,219 - INFO [QuorumPeer:/0.0.0.0:2181:FastLeaderElection@697] - Notification time out: 6400
複制
- 解決方案:
- Zookeeper本身的Bug: FastLeaderElection - leader ignores the round information when joining a quorum
- 重新開機下目前的Leader, 産生新的Leader.
zk的log和snapshot占用大量空間
- 現象: zk的datadir下的
下有大量的log和snapshot檔案, 占用大量的磁盤空間version-2
- 解決: 在配置檔案裡打開周期性自動清理的開關
, 當然也可以通過autopurge.purgeInterval=1
來設定需要保留的snapshot檔案個數,預設是3;autopurge.snapRetainCount
某台用戶端上有的程序可以連接配接到zk, 有的無法連接配接
- 現象: 同一台用戶端機器上啟動多個相同的程序, 有些程序無法連接配接到zk叢集
- zk服務端日志:
Too many connections from /x.x.x.x - max is x
複制
- 解決: zk的配置中
設定過小, 這個參數用來限制單個IP對zk叢集的并發通路;maxClientCnxns
一台zk伺服器無法對外提供服務,報錯"Have smaller server identifier, so dropping the connection."
- 現象:使用zkCli.sh無法連接配接成功該zk節點;
- 日志: 大量報錯:
Have smaller server identifier, so dropping the connection.
- 解決方案: 保持這台有問題zk的現狀, 按myid從小到大依次重新開機其他的zk機器;
- 原因: zk是需要叢集中所有機器兩兩建立連接配接的, 其中配置中的3555端口是用來進行選舉時機器直接建立通訊的端口, 大id的server才會去連接配接小id的server,避免連接配接浪費.如果是最後重新開機myid最小的執行個體,該執行個體将不能加入到叢集中, 因為不能和其他叢集建立連接配接
zk用戶端偶爾無法成功連接配接到zk server
- 現象: 同一台機器來運作的zk用戶端, 偶發無法成功連接配接到zk server
- 分析:
- 當時提供給業務一份sdk, sdk初始化時需要先連接配接zk, 初始化結束後斷開zk的連接配接,業務将這份sdk用在了由fpm-php 處理的前端web請求的php代碼中, 該業務的QPS在6K-8K左右, 相當于zk在處理大量的短連接配接請求;
- 在zk服務端監控下列指令的輸出, overflowed和droped的數值在不斷增加,說明 listen的accept queue有不斷被打滿的情況
[root@m1 ~]# netstat -s |grep -i listen
53828 times the listen queue of a socket overflowed
53828 SYNs to LISTEN sockets ignored
複制
- 解決:
- 調整相關核心參數:/proc/sys/net/ipv4/tcp_max_syn_backlog和net.core.somaxconn
- zk服務端listen時的backlog用的是預設值50, zk沒參數用來設定這個,有這個issue:Configurable listen socket backlog for the client port, 裡面提供了patch;
- 避免用戶端有大量短連接配接的方式連接配接zk服務;
-
深究:
關于tcp連接配接隊列,這篇文章很不錯: How TCP backlog works in Linux