こんにちは、Steffen。

バックアップ/リストアのコードパスをざっと見てみましたが、驚いたことにリストアコード自体は8.6.3と8.8.2の間で変更されていません。8.6.3と8.8.2の両方で、バックアップに記載されているconfigsetが現在ZooKeeperに存在するconfigと同じ名前の場合、ZKのバージョンが使用されます。したがって、バックアップ後にスキーマに追加されたフィールドは表示されるはずです。しかし、ご報告の通り、実際にはそうなっていません。これは、コレクション作成やスキーマ読み取りに何らかの動作の変化があることを示していると思います。

この問題の原因をさらに掘り下げて調査したいと思っています。その間、まだ行っていない場合は、この動作についてのJIRAチケットを提出していただけますか？

最後の質問です：上記で述べたように、フィールドが再起動後に表示されるとありましたが、リロード（/admin/collections?action=RELOAD&name=testcollection）でも同じ効果がありますか？もしそうであれば、短期的にはそちらの方法がより受け入れやすい回避策になるかもしれません。

よろしくお願いします。

Jason

こんにちは、Steffen。

あなたの最初のメールに記載されていた手順を使用して、8.8.2でこの問題を再現することができました（1つの逸脱を除いて、認証を有効にして「認証されていない要求から信頼されたbaseConfigSetを使用してconfigsetを作成できない」というエラーを回避する必要がありました）。

あなたがこの問題を引き起こすために使用している手順は少し奇妙です。実際にバックアップと一緒に保存されているconfigsetを編集することが本番ワークフローの一部ですか？それとも、再現を簡単にするためにこの手順を追加しましたか？スキーマAPIを使用することが推奨されており、次にconfigsetファイルを編集してZooKeeperにアップロードすることが推奨されます。この奇妙な手順があっても、これはバグであることに変わりありません。Solrが再起動するまでフィールドを拾わない理由は考えられません。

この再現をさらに進めるために、バックアップ/リストアを全く使わずにこの問題を再現することが可能です。重要な部分は、新しい（スキーマ編集後の）コレクションとconfig setが、削除された対応物と同じ名前を持っていることです。

1. Solrを起動します: bin/solr start -c -p 7574
2. 認証を有効にします（これは私が_configsetを作成するために必要でした）: bin/solr auth enable -type basicAuth -credentials solr:solrRocks -z localhost:8574
3. "_default"をベースにconfigを作成します: curl -ilk -X GET -u solr:solrRocks "http://localhost:7574/solr/admin/configs?action=CREATE&name=testconfigset&baseConfigSet=_default"
4. このconfigsetを使用してコレクションを作成します: curl -ilk -X GET -u solr:solrRocks "http://localhost:7574/solr/admin/collections?action=CREATE&name=coll1&collection.configName=testconfigset&numShards=1"
5. configsetをローカルにダウンロードします: bin/solr zk downconfig -d downloaded_test_config -n testconfig2 -z localhost:8574
6. 新しい定義をdownloaded_test_config/conf/managed-schemaに追加します
7. 既存のコレクションを削除します: curl -ilk -X GET -u solr:solrRocks "http://localhost:7574/solr/admin/collections?action=DELETE&name=coll1"
8. ZKからconfigsetを削除します: curl -ilk -X GET -u solr:solrRocks "http://localhost:7574/solr/admin/configs?action=DELETE&name=testconfigset"
9. ローカルコピーからconfigを作成します: bin/solr zk upconfig -d downloaded_test_config -n testconfigset -z localhost:8574
10. 以前のコレクションと同じ名前の新しいコレクションを作成します: curl -ilk -X GET -u solr:solrRocks "http://localhost:7574/solr/admin/collections?action=CREATE&name=coll1&collection.configName=testconfigset&numShards=1"
11. フィールドをリストして、追加されたフィールドが欠けていることを確認します: curl -ilk -X GET -u solr:solrRocks "http://localhost:7574/solr/coll1/schema/fields"

私の最良の推測では、Solrはconfigset（またはそれから解析されたスキーマ）をキャッシュしており、対応するconfigset/collectionが削除された後も残っているようです。しかし、私はconfigsetコードに詳しくないので、これ以上詳しく調査することはできません。誰か他の人がここから引き継ぐことを願っています。その間、RESTORE呼び出しに「collection.configName」パラメータを指定することで、バックアップされたconfigsetが異なる名前でZKにアップロードされるため、問題を引き起こしているキャッシュを回避できるかもしれません。

よろしくお願いします。

Jason

こんにちは、Jason。

この問題を確認し、再現できることを確認していただきありがとうございます。
申し訳ありません、サーバーをSOLR_OPTSに以下の設定をして起動したことを言い忘れていました。
-Dsolr.disableConfigSetsCreateAuthChecks=true -Dsolr.allowPaths=/var/solr_backup

この問題のために、以下のリンクにJIRAチケットを作成しました：
https://issues.apache.org/jira/browse/SOLR-15478
あなたの手順をコメントとして添付しました。

はい、コレクションをリロードしてみましたが、スキーマの変更を表示させることはできませんでした。
collection.configNameを指定してリストアを試してみます。

よろしくお願いします。

Steffen

ああ、なぜ私が「信頼された config-set」の警告に引っかかったのか不思議に思っていましたが、それで納得です。

チケットを作成していただきありがとうございます。「異なる config-name」を使った回避策が役立つかどうか非常に興味があります！

Jason