Non è comune vedere questo tipo di problema, ma l'ho visto verificarsi sporadicamente.
La migliore azione correttiva da intraprendere qui è ridurre il primario del frammento TO di riferimento che cancellerà le eliminazioni in background. I thread di eliminazione esistono solo sul primario corrente (saranno replicati da quel primario tramite il oplog man mano che vengono elaborati). Quando lo abbassi, diventa un secondario, i thread non possono più scrivere e ottieni un nuovo primario senza eliminazioni in sospeso. Potresti voler riavviare il precedente primario dopo lo step down per eliminare i vecchi cursori, ma di solito non è urgente.
Fatto ciò, rimarrai con un gran numero di documenti orfani, che possono essere indirizzi con cleanUpOrphaned comando
che consiglierei di eseguire in orari di traffico ridotto (se hai tali orari).
Per riferimento, se si tratta di un problema ricorrente, è probabile che i primari abbiano un po' di difficoltà in termini di carico e per evitare l'accodamento delle eliminazioni è possibile impostare _waitForDelete opzione
per il bilanciatore su true (false per impostazione predefinita) come segue:
use config
db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_waitForDelete" : true } },
{ upsert : true }
)
Ciò significa che ogni migrazione è più lenta (forse in modo significativo) ma non causerà l'accumulo di eliminazioni in background.
