私はSolrCloudをほとんど使ったことがありません。私の小さなインストールを、組み込みZKを使用してクラウドに変換しましたが、サーバーは1台、コレクションは1つ、コアも1つだけです。ZKにsolr.xmlはありません。これを行ったのは、必要が生じた場合にクラウド専用の機能にアクセスできるようにするためです。私は時々そのインストールをいじってサポートの質問に答えるようにしています。インデックスの再構築には約10分しかかかりませんので、何かを間違えた場合は、動作する設定を復元し、データディレクトリを削除して再起動し、再インデックスします。

/etc/default/solr.in.shだけを提供してSolrノードを起動できることには多くの価値があると思います。solrホームが完全に空でも、solr.xmlがZKにあればノードは起動します。

solr.xmlが全く見つからない場合にSolrがデフォルト設定で起動するようにするべきだと考えます。そして、そのデフォルト設定が何であるべきかについて議論することができます。

クラウドモードがsolr.xmlなしで起動できるようにすれば、多くの人がZKにsolr.xmlを保存する必要がなくなるでしょう。それにより、Dockerユーザーにとっても簡単になります。完全に空のボリュームをsolrホームにアタッチすれば、Solrが起動します。その後、カスタム設定を提供するためにsolr.xmlを追加することができます。

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

こんにちは、

Solr 9.0以降、空のSOLR_HOMEでも起動できるようになりました。デフォルトの設定が使用されるためです（https://solr.apache.org/guide/solr/9_0/upgrade-notes/major-changes-in-solr-9.htmlを参照）：「Solrはもう$SOLR_HOMEにsolr.xmlを必要としません。見つからない場合は、$SOLR_TIP/server/solr/solr.xmlのデフォルトのものが使用されます。」

したがって、solr.xmlを中央に保存する動機はもはや有効ではありません。

JIRAでのDavidのコメントにも同意します。これは、solr.xmlを概念的にどう位置づけるかという問題でもあります。ノード構成ファイルなのか、クラスタ構成ファイルなのかです。クラスタ全体の構成には他の場所があります。今日のところ、solr.xmlはその両方の混合です。「zkClientTimeout」のような値はクラスタ全体で共通にできる一方、「host」や「hostPort」は当然ノードごとにローカルです。

ローリングアップグレードシナリオも考えています。Solr 8.11から9.0へのローリングアップグレードを行うとき、9.0のノードには異なる構成が必要になるかもしれません。場合によっては、全く異なるXMLが必要になることもあります。現在、solr.xmlのほとんどの値はJavaのシステムプロパティから取得されています。これは、この設定がノードごとであることを強く示唆しています。

Jan

私もZKのsolr.xmlを使用している人を見たことがありませんし、solr.xmlはノード構成ファイルだと思います。ファイルシステムからのsolr.xmlの読み込みのみをサポートすることに非常に賛成です。

こんにちは、私たちは複数のリポジトリを単一ファイルに保存するために、ZKからsolr.xmlを使用しています。

ANNAMANENI：あなたが言う「複数のリポジトリ」とは具体的にどういう意味か説明していただけますか？おそらく「リポジトリ」はあなたのシステムに特有の意味を持っているのでしょう。この機能が削除された場合、何かが難しくなるのでしょうか？おそらく、まだDockerやコンテナを使用していないのではないかと推測します。

〜 David Smiley
Apache Lucene/Solr検索開発者
http://www.linkedin.com/in/davidwsmiley

信頼できるSolrをDockerで実行するためのガイドはありますか？いくつか見かけましたが、あなたが特に気に入っているものがあれば教えてください。

信頼できるSolrをDockerで実行するためのガイドはありますか？いくつか見かけましたが、あなたが特に気に入っているものがあれば教えてください。

https://solr.apache.org/guide/solr/latest/deployment-guide/solr-in-docker.html

これが公式ガイドです。元のdocker-solrリポジトリのドキュメントから移植されました。改善点はたくさんありますが、Dockerのリファレンスガイドページの改善に努力するべきです。

• Houston

私がどれだけ最新情報を把握していないかが分かりますね。もうすでに対応されていたとは知りませんでした。私は数年間、仕事でSolrを使っていないので、Solrの進展を詳しく追う時間がほとんどありません。教えてくれてありがとうございます。これで私の小さなSolrインストールからsolr.xmlを削除できると思います。

以下は別スレッド向けの話題ですが、これが非常に多くの作業を必要とすることは承知しています。できる限りお手伝いします。

構成システム全体の見直しが必要だと考えています。

1) すべての構成に一つのフォーマットを選ぶ。現在はxml、properties、jsonの混在です。jsonのコンパクトさが好きですが、公式の標準はコメントをサポートしておらず、私たちはアウトオブボックスのxml構成でコメントを多用しています。jsonを解析する多くのライブラリはコメントをサポートしていますが、非標準の拡張に依存するのは心配です。関連：JSONサポートについては、jacksonを使用するかnoggitを使用するかを決定し、他方を削除しましょう。他の依存関係がjacksonに依存している可能性が高く、選択が決まるかもしれません。jacksonを他のXML処理にも使用できますか？依存関係を減らし、ダウンロードを小さくしたいです。

2) 構成システム全体が適切な継承ルールに従っていることを確認します。クラスタ構成が優先され、ノード構成がそれを上書きするようにします。クラスタ構成はおそらくクラウドモードにのみ適用されるので、ZKにあり、管理UIで完全に構成可能にします。クラウドモードのデフォルトノード構成は実際にクラスタ構成の一部であり、ノード固有の上書きもZKに含めて中央で簡単に編集できるようにするのが望ましいです。/etc/default/solr.in.shに通常入れるものも中央で編集できると非常に便利です。

3) 管理UIにコレクション/コアの構成のUI内編集オプションを追加し、彼らができるすべてのことがUI内で利用可能であることを確認します。この機能はセキュリティ対策としてデフォルトでオフにし、オンにするボタンには大きな赤いセキュリティ警告を表示します。

すべてが管理UIで構成可能で、一部はセキュリティのためデフォルトでオフになっているSolrCloudの世界を想像しています。UIでヒープサイズを変更したり、複数のSolrノードを再起動したりすることが中央UIで行えるようにするのが理想です。UIがZKノードも制御できると非常に便利です。その一環として、スタンドアロンモードを廃止することが賢明かもしれません。

非常に野心的なアイデアとして、中央UIのIPアドレスの自動冗長性のためのVIPを作成するフルソフトウェアスイートを持つこと、rpmおよびdebリポジトリを用意して簡単にインストールできるようにすることが考えられます。現在、コンテナが非常に流行っているので、Dockerで同様のものを作成します。

ありがとうございます。
Shawn

ありがとう、Shawn

将来のメジャーバージョンに向けて設定の整理ができるといいですね。この件に関しては、ぜひ開発者リストでスレッドを立ち上げてください。

このスレッドで重要なのは、solr.xmlが何であり、何でないかを決定することだと思います。もう一つの重要なポイントは、solr.xmlの設定変更がノードの再起動を必要とするかどうかです。ほとんどの設定変更は再起動を必要とするようですので、これはノードローカルであることをさらに示唆しています。ZKのsolr.xmlを変更しても、その後にすべてのノードを再起動しない限り何も起こりません。そのため、結局のところ各ノードに触れる必要があります。

Jan Høydahl