zookeeper運営維持問題のまとめ
仕事の中で以下の問題に遭遇します:1、1台のzkノードが接続を失った後、再起動してずっとzkクラスタに参加することができなくて、対外的にサービスを提供することができません2、zkのlogとスナップショットが大量の空間を占めます3、クライアントの接続に失敗して成功します4、zkクライアントはたまに失敗して接続します5、エラーを報告します:smaller server identifier、so dropping
以上の問題は生産環境でよく発生する
1.zkはzkクラスタに参加できない
現象:zkCliを使用する.shはこのzkノードログに正常に接続できません:まずこのノードrestartを考えますが、問題は依然としてあります.だからzkのlogを見て、大量の以下のログがあります.
解決策:これは3.3.4バージョンのバグで、新しいバージョンでは3.5が修復されています.最新バージョンを使用することをお勧めします.このバージョンを使用している場合は、leaderを再起動することで解決するしかありません.
2.zkのlogとスナップショットが大量のスペースを占める
現象:zkのdatadirの下のversion-2の下には多くのスナップショットがあり、ログディレクトリの下には大きなログファイル(単一ファイルが大きすぎる)があり、一部のものは役に立たないので、定期的に解決策をクリアすることをお勧めします:zkのプロファイルに自動クリーンアップログとスナップショットのスイッチautopurgeを追加します.purgeInterval=1、もちろん1年以内にautopurge.snapRetainCountは、保存する必要があるsnapshotファイルの数を設定します.デフォルトは3つです.
3.クライアント接続に失敗し成功
現象:クライアントの接続はあるものはつながることができて、ある接続の失敗のログ:
4.zkクライアントはたまに失敗した接続がある
現象:クライアントがzkに接続できないことがある理由:
このような状況は複雑で、コードや論理に関係しており、zkが大量の短い接続要求を処理する場合、SYN QUEUEのaccept queueが満たされることがあるなど、現在のトラフィックに関係しており、接続に失敗することがあります.詳しくはこの文章を見ることができるhttps://blog.csdn.net/varyall/article/details/79681562解決策:synキューのサイズはシステムがネットワークの高同時性を制限するために使用され、具体的なパラメータは以下の通りである:net.ipv4.tcp_max_syn_backlogとnet.core.somaxconn、この2つの値を同じに設定すればいいです.小さすぎると、このような問題が発生します.量を増やして、あまり高くしないでください.生産環境における最終的な解決策はzkとの短い接続数を低減することであり、このような問題はほとんど起こらない.
5.エラー:smaller server identifier,so dropping
現象:クライアント接続を使用して接続できない、zkログを見て、多くのエラーを発見しました:smaller server identifier、so dropping解決方法:zkのmyidの大きさによって小さいから大きいまでzkサーバーを再起動して、まず問題のあるzkが再起動しないことを保証します.分析原因:zkはクラスタ内のすべてのマシンの2つの接続を確立する必要があり、そのうち配置中の3555ポートは選挙時にマシンが直接通信を確立するためのポートであり、大きいidのserverは小さいidのserverに接続し、接続の浪費を避けることができる.最後にmyidを再起動する最小のインスタンスである場合、他のクラスタと接続できないため、インスタンスはクラスタに追加できません.
以上の問題は生産環境でよく発生する
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バージョンのバグで、新しいバージョンでは3.5が修復されています.最新バージョンを使用することをお勧めします.このバージョンを使用している場合は、leaderを再起動することで解決するしかありません.
2.zkのlogとスナップショットが大量のスペースを占める
現象:zkのdatadirの下のversion-2の下には多くのスナップショットがあり、ログディレクトリの下には大きなログファイル(単一ファイルが大きすぎる)があり、一部のものは役に立たないので、定期的に解決策をクリアすることをお勧めします:zkのプロファイルに自動クリーンアップログとスナップショットのスイッチautopurgeを追加します.purgeInterval=1、もちろん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キューのサイズはシステムがネットワークの高同時性を制限するために使用され、具体的なパラメータは以下の通りである:net.ipv4.tcp_max_syn_backlogとnet.core.somaxconn、この2つの値を同じに設定すればいいです.小さすぎると、このような問題が発生します.量を増やして、あまり高くしないでください.生産環境における最終的な解決策はzkとの短い接続数を低減することであり、このような問題はほとんど起こらない.
5.エラー:smaller server identifier,so dropping
現象:クライアント接続を使用して接続できない、zkログを見て、多くのエラーを発見しました:smaller server identifier、so dropping解決方法:zkのmyidの大きさによって小さいから大きいまでzkサーバーを再起動して、まず問題のあるzkが再起動しないことを保証します.分析原因:zkはクラスタ内のすべてのマシンの2つの接続を確立する必要があり、そのうち配置中の3555ポートは選挙時にマシンが直接通信を確立するためのポートであり、大きいidのserverは小さいidのserverに接続し、接続の浪費を避けることができる.最後にmyidを再起動する最小のインスタンスである場合、他のクラスタと接続できないため、インスタンスはクラスタに追加できません.