moveChunkはデータ転送にTOシャードを使用できませんでした：新しいチャンクを受け入れることができません。

この種の問題が発生することは一般的ではありませんが、散発的に発生することはあります。

ここで実行する最善の修正アクションは、参照されているTOシャードのプライマリをステップダウンすることです。これにより、バックグラウンドの削除がクリアされます。削除スレッドは現在のプライマリにのみ存在します（oplogを介してそのプライマリから複製されます それらが処理されるとき）。ステップダウンすると、セカンダリになり、スレッドは書き込みできなくなり、保留中の削除のない新しいプライマリを取得します。ステップダウン後に以前のプライマリを再起動して古いカーソルをクリアすることもできますが、通常は緊急ではありません。

これを行うと、多数の孤立したドキュメントが残ります。これらのドキュメントは、 cleanUpOrphaned コマンド 交通量の少ない時間帯に走ることをお勧めします（そのような時間帯がある場合）。

参考までに、これが繰り返し発生する問題である場合は、プライマリが負荷の点で少し苦労している可能性があります。削除のキューイングを回避するには、 _waitForDelete オプション バランサーをtrue（デフォルトではfalse）にするには、次のようにします。

use config
db.settings.update(
   { "_id" : "balancer" },
   { $set : { "_waitForDelete" : true } },
   { upsert : true }
)

これは、各移行が遅くなることを意味しますが（おそらく大幅に遅くなります）、バックグラウンドの削除が蓄積されることはありません。