(The bot translated the original post https://lists.apache.org/thread/zpr3ck0npoygqkymq39dv4b1bohztlvh into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

ソース: Solr 4.7 SolrCloud、コレクション内に3つのシャード、7つのレプリカがあります。
ターゲット: Solr 9.1.1 SolrCloud、3つのシャードと3つのレプリカです。

ソースバージョンは、SOLR-5875を含むカスタムの4.7.0バージョンで、これは非常に小さなパッチです。ターゲットバージョンは未修正のSolr 9.1.1です。このクライアントはバージョンを変更することを望んでいません。

スキーマはAtomic Updateの要件を満たしているため、古いクラスターにクエリを実行し、新しいクラスターに書き込むことで移行を行っています。フィールドの1つにフィルタをかけ、結果を効率的にページングするためにcursorMarkを使用して、バッチ処理を行っています。

クエリスレッドは10000件のドキュメントのバッチを取得し、それをキューに投入します。その後、インデクシングスレッドが処理します。クエリ側は、URLを使ってHttp2SolrClientを使用し、ターゲット側はCloudHttp2SolrClientをzk情報とともに使用し、シャードリーダーにのみ送信するオプションを設定しています。ソースコレクションはNRT（Near Real Time）で、これは4.7がサポートしている唯一のものだからです。ターゲットはTLOGです。両方のSolrClientオブジェクトはHTTP 1.1を使用するように設定されています。

あるバッチでは、常にnumFound（見つかった数）よりも5件少ないドキュメントがインデックスされます。それは一貫しており、常に5件です。移行中は更新が停止されています。前回の実行では、このバッチのnumFoundは3824942件で、インデックスされた件数は3824937件でした。

クエリバッチは常に10000件ですが、最後のバッチは4937件です。インデックスバッチは常に1000件ですが、最後のバッチは937件です。

おそらく問題はないと思いますが、キューサイズは500000です。インデックススレッドは2つあります。

移行コードに問題があるとは思っていません。他のバッチ（フィルタクエリで作成されたもの）はすべて正常に動作しており、インデックスされたドキュメントの数はnumFoundと一致しています。ドキュメントの総数は3000万件強で、このバッチは全体の10％強です。

Solr 4.7.0で、numFoundがcursorMarkで取得した総ドキュメント数と一致しないという問題を見たことがある人はいますか？これが起こる原因として考えられるのは、各レプリカでnumDocsのカウントが異なる場合ですが、各シャードのすべてのレプリカでこれらのカウントが同じであることを確認しました。

もう1つの可能性としては、uniqueKeyの値が複数のシャードに現れることがありますが、これはcompositeIdルーターがあるため、起こりにくいはずです。この状況を検出する方法はありますか？SolrJプログラムでそれを検出するアイデアはありますが、Solr 4.7に何か組み込まれているものがあることを願っています。

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