こんにちはコミュニティの皆様、

ソースコードを確認したところ、フォロワーからの読み取りのみをサポートしていないようです。私の予想では、これはzookeeperからstate.jsonデータを取得し、リーダーを特定して、リーダーを含まない明示的なホワイトリストを渡すことで実現できると思います。これが目標を達成する唯一の方法であることを確認してもらえますか？

ありがとうございます、
Stephen

Jiraアイテムを実装するためにファイルを提出しました：

SOLR-15472 shards.preference は leader=false をサポートする必要があります

この変更で解決しようとしている問題は何ですか？

負荷の少ないマシンにクエリを送信しようとしていますか？もしそうなら、それはそれを行いません。
リーダーはフォロワーよりもわずかに多くの作業を行います。すべてのインデックス処理はローカルで行われ、それがほとんどの CPU 使用量を占めます。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

検索サーバーのsolrconfigから更新ハンドラを削除するだけで済むと思います。

SolrCloudでは、コレクションのすべてのコアが同じsolrconfig.xmlファイルを使用し、そのファイルはZooKeeperに格納されています。ディスク上のsolrconfig.xmlファイルは無視されます。

おっしゃる通り、非クラウド展開向けの提案は素晴らしいものですね。

Shawn

リーダーへの負荷を軽減することは有益な機能であると思われます。リーダーに対する高いクエリ負荷が非応答性を引き起こし、最終的にはクラスタ全体を使用不能にする連鎖的な障害が発生するケースがありました。

実際、レプリカが遅れていることがわかっているときに特定のクエリをリーダーだけに指示できると便利です。

• Bram

TLOG + PULL クラウドでリーダーからの読み取りを除外する方法について調査を行いました。更新が多い場合、クエリのスループットとレイテンシが改善されることが観察されました。私たちがテストしているパッチを追加しました。
https://issues.apache.org/jira/secure/attachment/13026792/SOLR-15472.patch

素晴らしい情報ですね。パッチを提供してくれたWei、ありがとう！私には合理的に見えますし、結果について聞けて興奮しています。パッチとTLOGを組み合わせた設計は良さそうです。

さて、解決すべき問題についての質問に移ります。BramとWeiがそれを十分に説明してくれています。高いレベルでの目標は、読み取りレプリカと書き込みレプリカの間で作業をよりよく分割し、運用上の要因を分離することです。

現時点では、各シャードに3つのレプリカがあり、いずれかが耐障害性としてリーダーになる可能性のある共有コレクションのアーキテクチャに興味があります。これには、おそらくTLOGとWeiのパッチが完璧に適合します。これはDaveの提案ではうまくいかないかもしれませんが、わずかに異なるセットアップには有用です。

Weiのパッチを公式リリースのために本流に統合するための次のステップは何でしょうか？

よろしくお願いします。
Stephen

みなさん、こんにちは。

喜んでお知らせしますが、WeiのパッチがTimothy Potterによって本流と8_x（8.10用）にマージされました。お二人とも、ありがとうございます！

次に気になるのは、もちろんSolr 8.10がいつ利用可能になるかです。

もちろん「リリースは事前に予定されていません」とオンラインで読んだことはありますが、この変更を楽しみにしているので、誰かが共有できる情報があれば教えていただけると嬉しいです。

よろしくお願いします！
Stephen

8.9がリリースされたばかりですので、8.10がある場合、歴史的な傾向に基づくとおそらく1〜3ヶ月後にリリースされるでしょう。もちろん、ここでは約束や保証はありません。