zookeeper問題總結

文章出處:https://www.jianshu.com/p/88ffb54fb43a

  • 實際工作中用到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

zk的log和snapshot佔用大量空間

  • 現象: zk的datadir下的version-2下有大量的log和snapshot文件, 佔用大量的磁盤空間
  • 解決: 在配置文件裏打開週期性自動清理的開關 autopurge.purgeInterval=1, 當然也可以通過 autopurge.snapRetainCount來設置需要保留的snapshot文件個數,默認是3;

某臺客戶端上有的進程可以連接到zk, 有的無法連接

  • 現象: 同一臺客戶端機器上啓動多個相同的進程, 有些進程無法連接到zk集羣
  • zk服務端日誌:
Too many connections from /x.x.x.x - max is x
  • 解決: zk的配置中maxClientCnxns設置過小, 這個參數用來限制單個IP對zk集羣的併發訪問;

一臺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
  • 分析:
    1. 當時提供給業務一份sdk, sdk初始化時需要先連接zk, 初始化結束後斷開zk的連接,業務將這份sdk用在了由fpm-php 處理的前端web請求的php代碼中, 該業務的QPS在6K-8K左右, 相當於zk在處理大量的短連接請求;
    2. 在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
  • 解決:
    1. 調整相關內核參數:/proc/sys/net/ipv4/tcp_max_syn_backlog和net.core.somaxconn
    2. zk服務端listen時的backlog用的是默認值50, zk沒參數用來設置這個,有這個issue:Configurable listen socket backlog for the client port, 裏面提供了patch;
    3. 避免客戶端有大量短連接的方式連接zk服務;
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章