再インデックス中に0件のライブドキュメントセグメントが残る
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/nbv2bqx7yzt3jh7x2sf6n8j3lwp68vqt into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
Luceneのリストでもこの質問を投げかけてみましたが、SolrのIndexReaderの扱いに関しても回答が得られるかもしれないと思い、こちらに投稿しました。
ドキュメントをセグメントごとに読み取り、同じインデックスに再インデックスするプログラムを実行しようとしています。LuceneのAPIを使用して読み取り、SolrのAPI（現在ロードされているコア内）を使用してインデックス作成を行い、フィールドの分析を保持し、削除を自動的に処理しています。処理されるセグメントはマージには参加しません。
再インデックスのコードはSolr内の同じJVMで実行されています。
私が観察しているのは、セグメントが完全に処理され、自動コミット（および自動ソフトコミット）が実行された後でも、0件のライブドキュメントを持つセグメントが残り、インデックスが膨らんでしまうことです。Solrを再起動すると、そのセグメントは正常にクリアされます。
コードなしで同じことを再現しようと試みたところ、空のテストコアに3件のドキュメントをインデックスし、その後同じドキュメントを再インデックスすると、古いセグメントはソフトコミットの間隔が経過するか、明示的なコミットが呼ばれるとすぐに削除されました。
以下は高レベルのコードです。しかし、このコードではSolrを再起動し、コアを再読み込みするまで未削除のセグメントが残ってしまいます。
try (FSDirectory dir = FSDirectory.open(Paths.get(core.getIndexDir()));
IndexReader reader = DirectoryReader.open(dir)) {
for (LeafReaderContext lrc : reader.leaves()) {
// 各リーフからライブドキュメントを読み取り、ドキュメントからSolrInputDocumentを作成し、Solr APIを使用してインデックスする
}
} catch(Exception e) {}
このようにIndexReaderを開くことがSolrのIndexReaderおよびファイル参照カウントの管理に干渉し、ファイルの削除を妨げる可能性があるのでしょうか？何か見落としている点はありますか？
必要であれば、コードやその他の詳細も提供できます。助けていただけると幸いです！
ありがとう、
Rahul
これを可能にするためには、ロック設定を「none」に変更している必要があります。Luceneは通常、同じインデックスを複数回開くのを防ぎますが、それには正当な理由があります。その状況での操作は未定義であり、インデックスが簡単に破損する可能性があります。
やるべきことは、インデックスディレクトリのコピーを作成し、そこからSolrにインデックスすることです。最初にrsyncを使ってコピーし、その後再度rsyncを実行すると、2回目のパスは非常に迅速に完了し、良好なインデックスが生成されるはずです。これには「rsync -avH --delete /path/to/source/ /path/to/target/」を使用するのが良いでしょう。
上記にも記載しましたが、Luceneはインデックスが複数回開かれるとどう動作するかについて保証を提供しません。LuceneのプログラムがSolrの参照カウントに干渉することはないでしょうが、Solrとあなたのプログラムの両方がインデックスを開くのは本当に悪いアイデアです。
Solrを再起動する代わりにコアを再読み込みすることを試してみることができます。これには非常に短い時間がかかり、Luceneが空のセグメントを削除するかもしれません。インデックスが大きくない場合は、SolrにmaxSegments=1でインデックスの最適化を依頼することもできます。ただし、非常に大きなインデックスにはそれを行いたくありません。
ありがとう、
Shawn
トピックへ返信するには、ログインが必要です。