Solr エラー
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/qp2kcnxnzmlqdnbbpykfd0wqq1gkf0sy into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、皆さん
新しいパソコン（Solr 5.5.1）でコレクションにエラーが発生しています。
私の新しいパソコンは1年半前に購入したもので、4TBのNVMe SSDを4つ搭載しています。
ディスクをチェックしましたが、エラーは見つかりませんでした。
何か解決できる方法をご存知でしょうか？
ご協力いただければ幸いです！
エラーメッセージは以下の通りです：
java.lang.IllegalStateException: this writer hit an unrecoverable error; cannot complete commit
at org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:2985)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2970)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2930)
at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:619)
at org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1464)
at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1264)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:231)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed
(hardware problem?) : expected=d0a2833f actual=64e63211
(resource=BufferedChecksumIndexInput(MMapIndexInput(path="C:\Users\Utilisateur\INDEX\FTCLAIMS\index\_8znd.cfs") [slice=_8znd.fdt]))
at org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:334)
at org.apache.lucene.codecs.CodecUtil.checksumEntireFile(CodecUtil.java:451)
at org.apache.lucene.codecs.compressing.CompressingStoredFieldsReader.checkIntegrity(CompressingStoredFieldsReader.java:669)
at org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.merge(CompressingStoredFieldsWriter.java:595)
at org.apache.lucene.index.SegmentMerger.mergeFields(SegmentMerger.java:177)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:83)
at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4075)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3655)
at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:588)
at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:626)
Bruno Mannina
こんにちは、
もう少し状況の説明をお願いできるでしょうか。というのも、なぜ Solr 5.5.1 を使っているのかという点が気になります。このバージョンは 2016 年にリリースされたもので、非常に古く、すでにサポート対象外です（重大なセキュリティ脆弱性も含まれています）。
そのため、問題を解決しようとするよりも、代わりに最新バージョン（9.8.1）への移行を検討できないでしょうか？ 過去 9 年間で多くの変更があったため、新たなスタートとして見直してみるのがよいかもしれません。
エラーメッセージから判断すると、ファイル が破損しているようです。ただし、これはディスク自体が破損しているという意味ではありません。その原因は明確ではないものの、過去のログを遡ることで手がかりが得られる可能性があります。
org.apache.lucene.index.CorruptIndexException について少し検索してみると、破損したインデックスを「修復」できる可能性があることが示唆されています（ただし、破損したドキュメントは失われる可能性があります）：
https://stackoverflow.com/a/14934177
とはいえ、本当におすすめするのは、サポートされているバージョンに移行し、元のデータから再インデックスを行うことです。
こんにちは Colvin さん、
ご返信とリンクのご共有、ありがとうございます。問題が解決できるかどうか、確認してみます。
古い Solr を使っていることは自覚しています…
この古いバージョンは何年も前から使われており、大量のデータ（約2億件のテキストファイル）をインデックス化しています。
このデータを再インデックスするには、私にとっては非常に時間がかかり（数週間）現実的ではありません。
これは本番用ではなく、プレプロダクション環境の Solr です（本番環境では Solr 8.11.3 を使用しています）。
このプレプロダクション環境は、本番環境へデータを移行する前に内容をチェックするために使用しています。
よろしくお願いいたします。
Bruno Mannina
こんにちは、Bruno さん
ちなみにですが、一般的には ステージング環境（プレプロダクション） の Solr インスタンスは、本番環境の Solr インスタンスと 可能な限りすべて（たとえば Solr のバージョンなど）を一致させるのが望ましいです。
もう一つの提案としては、複数のインデックス作成用マシンを用意して、それぞれが200Mのテキストファイルの一部を担当するようにすれば、全体のインデックス作成を高速化できるかもしれません。
よろしく、
Robi
マルチスレッドによるインデックス作成で処理速度を向上させることができます。
CPUあたり2スレッドを使用することで、最大のスループットが得られます。
私はそのためのシンプルな Python プログラムを書きました。
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
さらなる高速化の方法として、すでに実施していない場合は更新リクエストをバッチで送信することが挙げられます。
例えば、1件ずつのドキュメントで2億回リクエストを送るのではなく、1回のリクエストで200件ずつ送り、100万回のリクエストにすると効率的です。
もし更新データを XML形式 で送っているのであれば、JSON形式に切り替えることも検討してみてください。
Thomas
Solrとは直接関係ありませんが、次の点についてアドバイスさせてください：
ステージング環境（準本番環境）と本番環境は、必ず同じバージョンを使用するべきです。
特に、大きく異なるバージョンを使うのは意味がありません。
過去数年でSolrのAPIは変更され（V2も登場しています）、設定ディレクティブも新たに導入・廃止されており、デフォルトの挙動も変わっています。
古いバージョンでのテストは、実質的に何の価値もありません。
Mag.phil. Robert Ehrenleitner 工学士
こんにちは Robi さん、
実は、もう少し複雑な事情があります。
私は、データを本番環境に送る前にいくつかの処理を行う必要があります。
PreProd（準本番環境）は、本番にデータを送る前にそのデータをテストするためのものです。
手順は以下の通りです：
- プロバイダーからデータを受け取る
- 前処理を行う（翻訳、欠損データの補完、変換など）
- 準本番環境でフォーマット等をテストする
- 本番環境に送信し、インデックス化する
そのため、再インデックス化には今のところ時間がかかりすぎてしまいます。
昨年、準本番で再インデックス化を行いましたが、6か月もかかってしまいました…。
特に手順2と3が非常に時間を要し、手順4の後はデータを保持していません（大きすぎるため）。
つまり、時間がかかるのは再インデックス処理自体ではなく、前処理にあるのです。
よろしくお願いします
Bruno Mannina
こんにちは Bruno さん
なるほど、少なくともステップ2（前処理）は最適化できる余地がありそうですね。
たとえば、以下のようなワークフローを実現する小さなJavaプログラムを作ってみてはいかがでしょうか：
- 生データを受け取り、SolrJライブラリを使ってSolrドキュメントを構築する
- 必要な値を補完し、既存のデータを整形する（翻訳や変換など）
- 処理後のSolrドキュメントを別の場所に保存し、同時に準本番（PreProd）のSolrインスタンスに送信してテストを行う
- テストと検証が完了したら、その整ったSolrドキュメントをそのまま本番に送信するだけで済む
このようなワークフローが実現できれば、作業の効率がかなり改善されるかもしれません。
ただの提案ですが、参考になれば嬉しいです。
ありがとう
Robi
トピックへ返信するには、ログインが必要です。