Не е обичайно да се среща подобен проблем, но съм го виждал спорадично.
Най-доброто коригиращо действие, което трябва да предприемете тук, е да се оттеглите от основния на посочения TO фрагмент, което ще изчисти фоновите изтривания. Нишките за изтриване съществуват само в текущата основна (те ще бъдат репликирани от тази основна чрез oplog докато се обработват). Когато го намалите, той става вторичен, нишките вече не могат да пишат и получавате нов основен без чакащи изтривания. Може да искате да рестартирате предишния основен след стъпката надолу, за да изчистите старите курсори, но обикновено не е спешно.
След като направите това, ще останете с голям брой осиротели документи, които могат да бъдат адреси с cleanUpOrphaned команда
което бих препоръчал да работи при нисък трафик (ако имате такива).
За справка, ако това е повтарящ се проблем, вероятно първичните се борят малко по отношение на натоварването и за да избегнете опашката от изтривания, можете да зададете _waitForDelete опция
за балансира на true (false по подразбиране), както следва:
use config
db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_waitForDelete" : true } },
{ upsert : true }
)
Това ще означава, че всяка миграция е по-бавна (може би значително), но няма да доведе до натрупване на фонови изтривания.
