No es común ver este tipo de problema, pero lo he visto ocurrir esporádicamente.
La mejor acción correctiva que se puede tomar aquí es reducir el principal del fragmento TO al que se hace referencia, lo que eliminará las eliminaciones en segundo plano. Los subprocesos eliminados solo existen en el principal actual (se replicarán desde ese principal a través de oplog a medida que se procesan). Cuando lo baja, se convierte en secundario, los subprocesos ya no pueden escribir y obtiene un nuevo primario sin eliminaciones pendientes. Es posible que desee reiniciar el primario anterior después del paso hacia abajo para borrar los cursores antiguos, pero por lo general no es urgente.
Una vez que haga esto, se quedará con una gran cantidad de documentos huérfanos, que se pueden abordar con el cleanUpOrphaned comando
que recomendaría correr en tiempos de poco tráfico (si tiene esos tiempos).
Como referencia, si este es un problema recurrente, entonces es probable que las primarias tengan un poco de problemas en términos de carga, y para evitar la cola de eliminaciones, puede configurar _waitForDelete opción
para que el balanceador sea verdadero (falso por defecto) de la siguiente manera:
use config
db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_waitForDelete" : true } },
{ upsert : true }
)
Esto significará que cada migración será más lenta (quizás significativamente), pero no hará que se acumulen las eliminaciones en segundo plano.
