5 scénarios courants de dépannage MongoDB et correctifs rapides

Le dépannage MongoDB commence généralement lorsque votre application ralentit, que les écritures échouent ou qu'un jeu de répliques prend du retard. Ce guide présente cinq scénarios courants que vous rencontrerez probablement en production et montre où chercher en premier.

Utilisez ces vérifications comme première passe avant d'apporter des modifications plus importantes. Elles vous aident à séparer les problèmes de requêtes des problèmes d'infrastructure, de réplication ou de sharding.

1. Performances de requêtes lentes

Les requêtes lentes sont peut-être le problème de performance le plus courant signalé dans les environnements de production. Une requête qui prend des secondes au lieu de millisecondes peut gravement dégrader la réactivité de l'application.

Diagnostic : Utilisation de explain()

La première étape pour diagnostiquer une requête lente est de comprendre pourquoi elle est lente. La méthode explain() de MongoDB est l'outil essentiel pour cette analyse. Elle montre le plan d'exécution, détaillant quels index ont été utilisés (ou non).

Exemple de commande :

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

Analysez la sortie, en recherchant spécifiquement :

• winningPlan.stage : Si l'étape est COLLSCAN, MongoDB lit chaque document. Cela indique souvent un index manquant ou inutilisable.
• executionStats.nReturned comparé à executionStats.totalKeysExamined et executionStats.totalDocsExamined.

Correctifs rapides

1. Créez le bon index : Si le plan de requête montre un scan de collection, ajoutez un index qui correspond au filtre et au modèle de tri. Par exemple, si votre application recherche fréquemment des commandes par user_id et le timestamp le plus récent, créez un index composé :

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. Affinez la requête : Vérifiez si vous récupérez trop de données. Utilisez la projection pour ne renvoyer que les champs dont la page ou le travail a réellement besoin. 3. Examinez les journaux de requêtes lentes : Utilisez le profileur ou le journal des requêtes lentes avec un seuil adapté à votre charge de travail. Traitez tout seuil exact comme un choix opérationnel, pas une règle universelle.

Astuce : Les index améliorent la vitesse de lecture mais ralentissent légèrement les écritures. Indexez uniquement les champs fréquemment utilisés dans les prédicats de requête (find()), les opérations de tri (sort()) ou les requêtes de plage.

2. Retard de réplication dans les jeux de répliques

Le retard de réplication se produit lorsque les membres secondaires d'un jeu de répliques prennent un retard significatif par rapport au membre principal dans l'application des opérations de l'oplog (journal des opérations).

Diagnostic : Vérification de replSetGetStatus

Utilisez la commande replSetGetStatus sur n'importe quel membre du jeu de répliques pour examiner la santé et l'état de synchronisation de tous les membres.

Exemple de commande :

rs.printReplicationInfo()
// Ou en interrogeant directement l'état :
rs.status()

Recherchez optimeDate pour le primaire et les secondaires. La différence entre l'optime du primaire et celui d'un secondaire indique le retard, généralement affiché dans le champ secsBehind pour chaque membre.

Correctifs rapides

1. Vérifiez la latence réseau : Une latence élevée entre les membres peut ralentir le transfert de l'oplog.
2. Vérifiez le secondaire en retard : Un CPU élevé, des E/S disque lentes ou des charges de travail bruyantes peuvent empêcher un secondaire d'appliquer les écritures assez rapidement.
3. Examinez la couverture de l'oplog : Si le retard est sévère, le secondaire peut ne plus avoir les entrées d'oplog dont il a besoin. Dans ce cas, vous devrez peut-être resynchroniser ou reconstruire ce membre.

3. Erreurs de connexion et échecs d'authentification

Les services d'application ne parviennent souvent pas à se connecter à MongoDB en raison d'erreurs de configuration, de problèmes de pare-feu ou d'identifiants incorrects.

Diagnostic : Vérification des journaux et du réseau

Tout d'abord, vérifiez si le serveur MongoDB écoute sur l'adresse IP et le port attendus. Consultez les journaux du serveur MongoDB pour des erreurs spécifiques.

Erreurs de journal courantes :

• Address already in use : Un autre processus utilise le port.
• Connection refused : Le processus serveur est arrêté, bloqué ou écoute ailleurs.
• Authentication failed : Le nom d'utilisateur, le mot de passe, la base de données d'authentification ou l'attribution de rôle est erroné.

Correctifs rapides

1. Vérifiez les règles du pare-feu : Assurez-vous que le port MongoDB, souvent 27017, est accessible depuis les hôtes de l'application.
2. Vérifiez bindIp : Si mongod.conf ne lie qu'à 127.0.0.1, les clients distants ne peuvent pas se connecter. Liez à une interface privée spécifique lorsque c'est possible. Évitez 0.0.0.0 sauf si les contrôles réseau et l'authentification sont déjà en place.
3. Vérifiez authSource : Si l'utilisateur a été créé dans admin, la chaîne de connexion peut nécessiter ?authSource=admin.

4. Espace disque insuffisant

En tant que base de données documentaire, MongoDB stocke les données directement sur le disque. Une croissance inattendue des données ou des nettoyages de base de données mal gérés peuvent rapidement entraîner une saturation de l'espace disque, bloquant toutes les opérations d'écriture.

Diagnostic : Surveillance et db.stats()

Utilisez les outils de surveillance du système d'exploitation (df -h sur Linux) pour vérifier l'utilisation globale du disque. Dans MongoDB, utilisez la commande db.stats() pour voir l'espace consommé par chaque base de données individuelle.

Exemple de commande :

db.stats()

Regardez spécifiquement les champs storageSize et dataSize.

Correctifs rapides

1. Gagnez du temps si les écritures échouent : Arrêtez les tâches non essentielles, supprimez les fichiers temporaires non liés, ou augmentez le volume si votre plateforme le permet.
2. Supprimez les données inutilisées : Supprimez les anciennes collections ou bases de données uniquement après avoir confirmé qu'elles ne sont plus nécessaires et que des sauvegardes existent.
3. Compactez avec précaution : Pour les collections avec de nombreuses suppressions ou mises à jour, compact peut libérer de l'espace réservé, mais peut être perturbateur. Testez l'impact pour votre version de MongoDB et votre moteur de stockage :

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. Augmentez la capacité de stockage : La solution à long terme est généralement des disques plus grands, de meilleures règles de conservation, ou un stockage séparé pour les journaux et les sauvegardes.

Avertissement : Si le disque se remplit complètement, MongoDB cessera d'écrire pour éviter la corruption des données. Vous devez résoudre les problèmes d'espace avant de tenter de reprendre les opérations normales.

5. Erreurs de cluster sharding (routeurs/serveurs de configuration obsolètes)

Dans les environnements shardés, des problèmes de connectivité ou d'état au sein des serveurs de configuration (config servers) ou des routeurs de requêtes (instances mongos) peuvent bloquer l'ensemble du système.

Diagnostic : Vérification de la santé du cluster

La commande sh.status() exécutée sur une instance mongos est l'outil de diagnostic principal pour la santé du sharding.

Exemple de commande exploitable :

sh.status()

Les domaines clés à vérifier dans la sortie incluent :

• Serveurs de configuration : Confirmez que le jeu de répliques du serveur de configuration a une majorité saine.
• Shards : Vérifiez que chaque shard listé est connecté et rapporte correctement.
• État obsolète : Recherchez des avertissements indiquant qu'un routeur ou un shard a des métadonnées obsolètes.

Correctifs rapides

1. Redémarrez mongos si nécessaire : Si un routeur est obsolète ou ne répond pas, le redémarrer peut forcer une nouvelle connexion aux serveurs de configuration.
2. Corrigez d'abord la santé du serveur de configuration : Si le jeu de répliques du serveur de configuration manque d'une majorité saine, les opérations de métadonnées de shard peuvent échouer.
3. Résolvez les problèmes au niveau du shard : Si un shard est en panne en raison d'une pression disque ou d'un retard de réplication, corrigez cette cause racine avant de chercher les symptômes du routeur.

Quand consulter un professionnel

Faites appel à un administrateur MongoDB ou à un ingénieur de plateforme lorsqu'une perte de données est possible, qu'un jeu de répliques nécessite une resynchronisation, que les serveurs de configuration ne sont pas sains, ou que l'espace disque affecte déjà les écritures. Obtenez de l'aide avant d'exécuter des commandes perturbatrices telles que la compaction ou la reconstruction de membres en production.

À retenir

Commencez le dépannage MongoDB par le symptôme le plus proche de l'impact utilisateur : page lente, connexion échouée, écriture bloquée, secondaire en retard, ou erreur de cluster shardé. Utilisez ensuite explain(), rs.status(), db.stats() et sh.status() pour confirmer la cause avant de modifier les index, redémarrer les routeurs ou reconstruire les membres.