Ce n'est pas courant de voir ce genre de problème, mais je l'ai vu se produire sporadiquement.
La meilleure mesure corrective à prendre ici est de supprimer le primaire du fragment TO référencé, ce qui effacera les suppressions d'arrière-plan. Les threads de suppression n'existent que sur le primaire actuel (ils seront répliqués à partir de ce primaire via l'oplog au fur et à mesure de leur traitement). Lorsque vous le réduisez, il devient secondaire, les threads ne peuvent plus écrire et vous obtenez un nouveau primaire sans suppressions en attente. Vous souhaiterez peut-être redémarrer l'ancien curseur principal après l'étape précédente pour effacer les anciens curseurs, mais ce n'est généralement pas urgent.
Une fois que vous faites cela, il vous restera un grand nombre de documents orphelins, qui peuvent être des adresses avec le cleanUpOrphaned commande
que je recommanderais de courir à des heures de faible trafic (si vous avez de telles heures).
Pour référence, s'il s'agit d'un problème récurrent, il est probable que les primaires aient un peu de mal en termes de charge, et pour éviter la file d'attente des suppressions, vous pouvez définir le _waitForDelete possibilité
pour l'équilibreur sur true (false par défaut) comme suit :
use config
db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_waitForDelete" : true } },
{ upsert : true }
)
Cela signifie que chaque migration est plus lente (peut-être de manière significative) mais n'entraînera pas l'accumulation des suppressions en arrière-plan.
