こちらのリンク（https://solr.apache.org/guide/6_6/index-replication.html）を再確認すると、少しずつ全体像が見えてきました。私の推測では、参照されている一時ディレクトリが index. ディレクトリだと思います。

フルレプリケーションを引き起こすケースに非常に興味があります。私の知る限り、問題のコアに対して最適化コマンドは発行されていません。

最適化または大規模なフラグメントマージが発生した場合のみ、大きなファイルがそこに生成されます。ですから、「スレーブ」は常にインデックスサイズの2倍の容量を確保しておくべきです。Solrはマスターでのマージや最適化のタイミングを独自に判断するため、スレーブはその2倍のサイズに対応できるように準備しておく必要があり、マスターは3倍のサイズに対応できるようにしておく必要があります。このディスク容量を確保していないと、最終的に深刻な問題に直面するか、単にレプリケーションができなくなってしまうでしょう。

-dave

ありがとうございます、Dave！はい、昨日この問題に直面し、ディスク容量と大きなコアサイズを見直す必要があると感じました。また、このイベントには興味深い背景がありました。マスターからレプリケーションしている2つのスレーブが別々のサーバーにあります。週末に1つのスレーブは正常にレプリケーションされ、更新が必要なファイルはごく一部でした。しかし、もう1つのスレーブでは、Solrが完全なレプリケーションが必要だと認識し、ディスクを埋め尽くしては失敗し、失敗した試みをクリーンアップして再度試みるということを繰り返していました。昨日、いくつかのSolr再起動と完全なSolrスタート/ストップの後、Solrが完全なレプリケーションを必要としないことを認識し、必要なインデックスファイルのサブセットをコピーするだけで正常に完了しました（他のスレーブと同様に）。

一時的にSolrが完全なレプリケーションを必要とする状態になっており、ストップ/スタートによってレプリケーションに実際に必要なものを再評価させたとしか説明できません。現在、両方のレプリケーションは正常です。

Matt

スレーブが互いに異なる動作をしたり、インデックスのバージョンがずれてしまうことを見たことがあります。通常、これは1つのスレーブとマスター間のレイテンシーが他のスレーブと異なる場合に発生します。しかし、繰り返しになりますが、スレーブには少なくともインデックスのサイズの2倍のディスク容量を確保するべきです。さらに、スレーブが同じディスク容量とメモリを持っているかどうか、またはネットワーク外のスレーブがある場合は、レプリケーションのタイムアウトを延長して、すぐ近くのサーバーと競合しないようにすることも検討してください。

全体的にこれはダンスのようなものです。例えば、問題を起こして再レプリケーションしているサーバーが途中でインデックスが変更されたために新しい一時インデックスフォルダを作成して同じプロセスを繰り返す必要があるということもあります。本当に興味深いことがたくさん起こります。

それでは、頑張ってください。経験からのもう一つのアドバイスとして、クイーン（主要なスレーブ）を1つだけ使用し、他はバックアップとして使用することをお勧めします。1つのサーバーがラウンドロビンや他のメトリックを使用してサーバーを決定するよりも、フィールドをキャッシュするのがはるかに速いです。

-Dave

再度ありがとう、Dave。役立つ情報です！はい、私たちは1つのスレーブをプライマリとして使用してクエリに応答し、もう1つをフェイルオーバー用にしています。SolrCloud Solr 8/9への移行を徐々に進めていますが、まだSolr 6のデプロイメントの維持に多くの作業が割かれています。このようなレプリケーションについて学ぶことは非常に価値があります。

Matt