5 scenari comuni di risoluzione dei problemi di MongoDB e soluzioni rapide

La risoluzione dei problemi di MongoDB di solito inizia quando la tua app diventa lenta, le scritture falliscono o un set di replica resta indietro. Questa guida illustra cinque scenari comuni che potresti incontrare in produzione e mostra dove guardare per primo.

Usa questi controlli come primo passo prima di apportare modifiche più grandi. Ti aiutano a separare i problemi di query da quelli di infrastruttura, replica o sharding.

1. Prestazioni di query lente

Le query lente sono forse il problema di prestazioni più comune segnalato in ambienti di produzione. Una query che impiega secondi invece di millisecondi può degradare gravemente la reattività dell'applicazione.

Diagnosi: utilizzo di explain()

Il primo passo per diagnosticare una query lenta è capire perché è lenta. Il metodo explain() di MongoDB è lo strumento essenziale per questa analisi. Mostra il piano di esecuzione, dettagliando quali indici sono stati utilizzati (o non utilizzati).

Esempio di comando:

db.collection.find({ field: 'value' }).explain('executionStats')

Analizza l'output, cercando in particolare:

• winningPlan.stage: Se lo stage è COLLSCAN, MongoDB sta leggendo ogni documento. Questo spesso indica un indice mancante o inutilizzabile.
• executionStats.nReturned confrontato con executionStats.totalKeysExamined e executionStats.totalDocsExamined.

Soluzioni rapide

1. Crea l'indice giusto: Se il piano di query mostra una scansione della collezione, aggiungi un indice che corrisponda al filtro e al modello di ordinamento. Ad esempio, se la tua app cerca frequentemente ordini per user_id e timestamp più recente, crea un indice composto:

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. Affina la query: Controlla se stai recuperando troppi dati. Usa la proiezione per restituire solo i campi di cui la pagina o il job hanno effettivamente bisogno. 3. Rivedi i log delle query lente: Usa il profiler o il log delle query lente con una soglia adatta al tuo carico di lavoro. Considera qualsiasi soglia esatta come una scelta operativa, non una regola universale.

Suggerimento: Gli indici migliorano la velocità di lettura ma rallentano leggermente le scritture. Indicizza solo i campi che vengono utilizzati frequentemente nei predicati delle query (find()), nelle operazioni di ordinamento (sort()) o nelle query di intervallo.

2. Ritardo di replica nei set di replica

Il ritardo di replica si verifica quando i membri secondari di un set di replica restano significativamente indietro rispetto al membro primario nell'applicare le operazioni dall'oplog (log delle operazioni).

Diagnosi: verifica di replSetGetStatus

Usa il comando replSetGetStatus su qualsiasi membro del set di replica per esaminare lo stato di salute e sincronizzazione di tutti i membri.

Esempio di comando:

rs.printReplicationInfo()
// Oppure interrogando direttamente lo stato:
rs.status()

Cerca optimeDate per il primario e i secondari. La differenza tra l'optime del primario e quello di un secondario indica il ritardo, solitamente mostrato nel campo secsBehind per ogni membro.

Soluzioni rapide

1. Controlla la latenza di rete: Un'alta latenza tra i membri può rallentare il trasferimento dell'oplog.
2. Controlla il secondario in ritardo: CPU elevata, I/O del disco lento o carichi di lavoro "rumorosi" possono impedire a un secondario di applicare le scritture abbastanza velocemente.
3. Rivedi la copertura dell'oplog: Se il ritardo è grave, il secondario potrebbe non avere più le voci dell'oplog di cui ha bisogno. In tal caso, potrebbe essere necessario risincronizzare o ricostruire quel membro.

3. Errori di connessione e fallimenti di autenticazione

I servizi applicativi spesso non riescono a connettersi a MongoDB a causa di errori di configurazione, problemi del firewall o credenziali errate.

Diagnosi: verifica dei log e della rete

Prima, verifica se il server MongoDB è in ascolto sull'indirizzo IP e sulla porta previsti. Controlla i log del server MongoDB per errori specifici.

Errori comuni nei log:

• Address already in use: Un altro processo sta usando la porta.
• Connection refused: Il processo del server è fermo, bloccato o in ascolto altrove.
• Authentication failed: Il nome utente, la password, il database di autenticazione o l'assegnazione del ruolo sono errati.

Soluzioni rapide

1. Controlla le regole del firewall: Assicurati che la porta di MongoDB, spesso 27017, sia raggiungibile dagli host dell'applicazione.
2. Verifica bindIp: Se mongod.conf si lega solo a 127.0.0.1, i client remoti non possono connettersi. Quando possibile, lega a un'interfaccia privata specifica. Evita 0.0.0.0 a meno che i controlli di rete e l'autenticazione non siano già in atto.
3. Controlla authSource: Se l'utente è stato creato in admin, la stringa di connessione potrebbe aver bisogno di ?authSource=admin.

4. Esaurimento dello spazio su disco

Come database documentale, MongoDB memorizza i dati direttamente sul disco. Una crescita imprevista dei dati o pulizie del database gestite in modo improprio possono portare rapidamente all'esaurimento dello spazio su disco, bloccando tutte le operazioni di scrittura.

Diagnosi: monitoraggio e db.stats()

Usa gli strumenti di monitoraggio del sistema operativo (df -h su Linux) per controllare l'utilizzo complessivo del disco. All'interno di MongoDB, usa il comando db.stats() per vedere quanto spazio stanno consumando i singoli database.

Esempio di comando:

db.stats()

Guarda in particolare i campi storageSize e dataSize.

Soluzioni rapide

1. Guadagna tempo se le scritture falliscono: Ferma i job non essenziali, rimuovi file temporanei non correlati o espandi il volume se la tua piattaforma lo supporta.
2. Rimuovi i dati inutilizzati: Elimina vecchie collezioni o database solo dopo aver confermato che non sono più necessari e che esistono backup.
3. Compatta con cautela: Per le collezioni con molte eliminazioni o aggiornamenti, compact può liberare spazio riservato, ma può essere dirompente. Testa l'impatto per la tua versione di MongoDB e il motore di archiviazione:

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. Aumenta la capacità di archiviazione: La soluzione a lungo termine sono solitamente dischi più grandi, migliori regole di conservazione o archiviazione separata per log e backup.

Avvertenza: Se il disco si riempie completamente, MongoDB smetterà di scrivere per prevenire il danneggiamento dei dati. Devi risolvere i problemi di spazio prima di tentare di riprendere le normali operazioni.

5. Errori del cluster di sharding (router/config server obsoleti)

In ambienti con sharding, problemi di connettività o stato all'interno dei server di configurazione (config servers) o dei router di query (istanze mongos) possono bloccare l'intero sistema.

Diagnosi: verifica della salute del cluster

Il comando sh.status() eseguito su un'istanza mongos è lo strumento diagnostico principale per la salute dello sharding.

Esempio di comando attuabile:

sh.status()

Le aree chiave da controllare nell'output includono:

• Config servers: Conferma che il set di replica del config server abbia una maggioranza sana.
• Shard: Verifica che ogni shard elencato sia connesso e stia riportando correttamente.
• Stato obsoleto: Cerca avvisi che un router o uno shard abbia metadati obsoleti.

Soluzioni rapide

1. Riavvia mongos quando appropriato: Se un router è obsoleto o non risponde, riavviarlo può forzare una nuova connessione ai config server.
2. Ripara prima la salute del config server: Se il set di replica del config server non ha una maggioranza sana, le operazioni sui metadati dello shard possono fallire.
3. Risolvi i problemi a livello di shard: Se uno shard è giù a causa di pressione sul disco o ritardo di replica, risolvi quella causa principale prima di inseguire i sintomi del router.

Quando consultare un professionista

Coinvolgi un amministratore di MongoDB o un ingegnere della piattaforma quando è possibile la perdita di dati, un set di replica necessita di una risincronizzazione, i config server non sono sani o lo spazio su disco sta già influenzando le scritture. Chiedi aiuto prima di eseguire comandi dirompenti come la compattazione o la ricostruzione dei membri in produzione.

Conclusione

Inizia la risoluzione dei problemi di MongoDB con il sintomo più vicino all'impatto sull'utente: pagina lenta, connessione fallita, scrittura bloccata, secondario in ritardo o errore del cluster shardato. Quindi usa explain(), rs.status(), db.stats() e sh.status() per confermare la causa prima di modificare gli indici, riavviare i router o ricostruire i membri.