Es ist nicht üblich, diese Art von Problem zu sehen, aber ich habe es sporadisch gesehen.
Die beste Abhilfemaßnahme, die Sie hier ergreifen können, besteht darin, die primäre des referenzierten TO-Shard herunterzufahren, wodurch die Hintergrundlöschungen gelöscht werden. Die Lösch-Threads existieren nur auf der aktuellen Primärdatenbank (sie werden von dieser Primärdatenbank über oplog repliziert). wie sie verarbeitet werden). Wenn Sie es herunterstufen, wird es zu einem sekundären, die Threads können nicht mehr schreiben und Sie erhalten ein neues primäres ohne ausstehende Löschungen. Möglicherweise möchten Sie die frühere primäre Version nach dem Herunterfahren neu starten, um alte Cursor zu löschen, aber dies ist normalerweise nicht dringend.
Sobald Sie dies getan haben, werden Sie mit einer großen Anzahl verwaister Dokumente zurückbleiben, die mit dem cleanUpOrphaned Befehl
was ich empfehlen würde, zu Zeiten mit wenig Verkehr zu laufen (wenn Sie solche Zeiten haben).
Wenn dies ein wiederkehrendes Problem ist, dann ist es wahrscheinlich, dass die Vorwahlen ein wenig mit der Auslastung zu kämpfen haben, und um das Anstehen von Löschvorgängen zu vermeiden, können Sie die _waitForDelete Möglichkeit
für den Balancer auf true (standardmäßig false) wie folgt:
use config
db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_waitForDelete" : true } },
{ upsert : true }
)
Dies bedeutet, dass jede Migration langsamer ist (vielleicht erheblich langsamer), führt jedoch nicht dazu, dass sich die Hintergrundlöschungen anhäufen.
