リーダー選出の遅延
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/6qyrvxk1rcxtnrl6rj7wdnzb8ncrgwoj into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
みなさん、こんにちは。
リーダー選出の遅延（Leader Election Slowness）について、コミュニティからのフィードバックをお願いしたいです。
これは私のチームが管理している Solr 8 および 9 のクラウド環境（様々なサイズ）の両方で発生しています。
この問題を再現しようとして Overseer（オーバーシア）の深いところに入り込んでしまいましたが、本格的に掘り下げる前に少し外の空気を吸いたくて投稿しています :-)
状況の説明：
ここで言う「遅い」とは、リーダー選出に30秒以上（時には1分以上）かかることを意味します。
この遅延は、ZooKeeper 上のライブノードの更新のタイミングにギャップが見られることで判明します（すべてのホストで確認できます）：
2025-04-04 22:23:29.150 INFO ZkStateReader [...] - Updated live nodes from ZooKeeper... (16) -> (15)
このログのあと、約40秒間にわたって一貫して起きているのは、indexFetcher がインデックスの同期状態を確認するループだけのようです。
そしてようやく 40 秒後に次のようなログが出力されます：
2025-04-04 22:24:01.041 INFO ZkStateReader [...] - A cluster state change: [...] has occurred - updating...
2025-04-04 22:24:03.665 INFO ShardLeaderElectionContext [...] - I am the new leader: http://new-leader-url.com/solr/...
2025-04-04 22:24:03.672 INFO IndexFetcher [...] - Updated leaderUrl to http://new-leader-url.com/solr/...
疑問点：
私が特に困惑しているのは、最初の約40秒の空白期間です。
この例ではクラウド構成としては比較的小規模で、2つのコレクションと合計31シャードしかありません。
ZooKeeper のメトリクスやログにも怪しいものは見当たりませんでした。
同じような現象を経験された方がいれば、ぜひ詳細や調査結果を共有していただけないでしょうか？
現在までの調査内容：
再現を試みる中で、Overseerの挙動をデバッグログで追うことになりました。
その過程で Matt Biscocho さんから、Overseer を廃止し distributedClusterStateUpdates と楽観的ロックを使う方向の取り組み（SOLR-14927）について教えていただきました。
これを試してみるのも面白そうですが、現時点ではこの問題を安定して再現できないため、その改善効果を正確に測る自信がありません。
また、我々のクラウドは通常 1～2コレクション／数十シャード程度なので、クラスタ状態更新の並列化による恩恵がどれほどあるのかも微妙なところです。
このスレを読んでいる方の中には、我々よりもはるかに大規模なクラウドで運用されている方も多いと思います。
ありがとうございます！
Luke
こんにちは、Angadさん。
ご提案ありがとうございます。leaderVoteWait はよくある原因だと私も思います。今回の私たちのケースでは該当しませんでしたが、それでもご指摘に感謝します！
参考までに、
Matthew Biscocho と私でこの問題について詳細に調査しました。複数の層に分かれた原因がありました。以下は、私たちの環境で発生した「遅い」リーダー選出の概要です：
- 現在のリーダーが
SIGTERMを受け取り、正常なシャットダウンを開始する。 - 下記のバグ（SOLR-17745）のために、SOLR-14942 で導入されたリーダー選出の最適化処理がスキップされる。
- リーダーがコアのクローズ処理を開始する。この処理は、シャットダウン時に大量のインジェストが発生していると、セグメントマージやファイルフラッシュの影響で長時間かかることがある。
- シャットダウン開始から5秒後、私たちのコンテナオーケストレーションシステムが
SIGKILLを送信し、コアのクローズ処理が完了しないままプロセスが強制終了される。そのため、zkSys/ZkContainer::closeに到達せず、本来であればリーダー選出用のエフェメラルZKノードを削除する処理が実行されず、後継ノードがリーダーとして選出されるシグナルが送られない。 zkClientTimeoutはデフォルトの30秒のままだったため、Zookeeper はリーダーからのハートビートが30秒間途絶えて初めて、そのノードが削除されたと認識し、後継ノードに情報が伝播される。結果的に、私たちのケースでは約35秒のダウンタイムが発生した。
— Luke
トピックへ返信するには、ログインが必要です。