Não é comum ver esse tipo de problema, mas tenho visto isso ocorrer esporadicamente.
A melhor ação corretiva a ser tomada aqui é reduzir o primário do fragmento TO referenciado, que limpará as exclusões em segundo plano. Os threads de exclusão existem apenas no primário atual (eles serão replicados desse primário através do
oplog à medida que são processados). Quando você o desativa, ele se torna um secundário, os threads não podem mais gravar e você obtém um novo primário sem exclusões pendentes. Você pode querer reiniciar o antigo primário após a redução para limpar os cursores antigos, mas geralmente não é urgente. Depois de fazer isso, você ficará com um grande número de documentos órfãos, que podem ser endereços com o
cleanUpOrphaned comando
que eu recomendaria rodar em horários de baixo tráfego (se você tiver esses horários). Para referência, se esse for um problema recorrente, é provável que as primárias estejam com um pouco de dificuldade em termos de carga e, para evitar o enfileiramento de exclusões, você pode definir o
_waitForDelete opção
para o balanceador como verdadeiro (falso por padrão) da seguinte forma:use config
db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_waitForDelete" : true } },
{ upsert : true }
)
Isso significa que cada migração é mais lenta (talvez significativamente), mas não fará com que as exclusões em segundo plano se acumulem.
