Erreurs de configuration MongoDB : correctifs pratiques et vérification

La configuration fait ou défait les déploiements MongoDB : elle façonne la sécurité, la durabilité, la performance et les opérations au jour le jour. Ce guide met en lumière les erreurs de configuration MongoDB les plus fréquentes, montre comment les corriger en toute sécurité et fournit des étapes de vérification et de retour arrière sur lesquelles vous pouvez compter. L'approche est pratique : vérifications concrètes, modifications petites et réversibles, et signaux clairs confirmant que le correctif a fonctionné.

Pour qui : développeurs, consultants DevOps et équipes techniques de startups qui exploitent MongoDB pour des API (par exemple Node.js et Express) ou des services internes.

Ce que vous obtenez : une étape d'inventaire courte, un chemin de configuration sûr avec exemples, vérification et diagnostics, modes de défaillance et récupération, et une liste de contrôle opérationnelle réutilisable.

Inventaire de la version et de l'environnement

Avant de changer quoi que ce soit, capturez un bref inventaire pour savoir ce qui peut être modifié en ligne, ce qui exige un redémarrage et ce qui nécessite un déploiement progressif.

Collectez :

• Édition et version de MongoDB
• Topologie : standalone, ensemble de réplicas ou cluster sharding
• Moteur de stockage et chemin des données
• Statut de l'authentification et de TLS
• Limites de ressources (descripteurs de fichiers), profil CPU/RAM/disque, type de système de fichiers

Commandes rapides :

• Version du serveur : mongod --version (shell) ou db.version() dans mongosh
• Topologie : rs.status() pour les ensembles de réplicas, sh.status() pour le sharding
• Source de configuration : db.adminCommand({getCmdLineOpts: 1}) pour voir la config analysée
• Statut auth : essayez db.runCommand({connectionStatus: 1})
• TLS activé/désactivé : vérifiez db.adminCommand({getParameter: 1, tlsMode: 1}) ou les logs au démarrage

Prérequis pour un travail sûr :

• Une sauvegarde récente et testée des données et de /etc/mongod.conf (ou votre chemin de config)
• Fenêtre de maintenance dimensionnée selon l'étape la plus disruptive (redémarrages, reconfigurations)
• Accès à tous les nœuds et capacité d'arrêter/démarrer le service
• Une portée pilote réduite d'abord (par exemple un secondaire) avant les changements cluster-wide

Chemin de configuration sûr

Cette section liste les erreurs à fort impact, comment les détecter et comment les corriger en toute sécurité avec des étapes concrètes.

1. Liaison réseau ouverte et pas d'authentification

Symptômes :

• MongoDB accessible depuis des réseaux non approuvés
• Vous pouvez exécuter des commandes d'administration sans identifiants

Vérification :

use admin
// Affiche net.bindIp analysé et security.authorization
db.adminCommand({getCmdLineOpts: 1})

Cherchez net.bindIp et security.authorization. Si bindIp inclut 0.0.0.0 ou si authorization est désactivé, corrigez-le.

Correctif sûr :

• S'il n'y a pas encore d'utilisateurs, créez un compte admin via l'exception localhost, puis activez l'auth.
• Liez uniquement aux interfaces requises (loopback plus une adresse privée) ou un VIP de load balancer.

Exemple d'étapes :

# 1. Créez le premier utilisateur admin (seulement si aucun utilisateur n'existe encore)
mongosh --host 127.0.0.1 --port 27017

use admin
db.createUser({
  user: 'siteRootAdmin',
  pwd: 'REMPLACER_PAR_MOT_DE_PASSE_FORT',
  roles: [ { role: 'root', db: 'admin' } ]
})

Éditez la config (exemple : /etc/mongod.conf) :

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.10
security:
  authorization: enabled

Redémarrez le service et vérifiez que l'accès non authentifié est bloqué et que la connexion admin fonctionne.

2. TLS désactivé ou passage brutal à requireTLS

Symptômes :

• Données en transit non chiffrées
• Clients cassés quand vous basculez vers requireTLS sans période de transition

Vérification :

use admin
db.adminCommand({getParameter: 1, tlsMode: 1})
// Ou vérifiez les logs pour 'TLS' au démarrage

Migration sûre vers TLS :

• Étape 1 : transitionToTLS (accepte à la fois TLS et non-TLS)
• Étape 2 : requireTLS une fois que tous les clients utilisent TLS

Exemple de config :

net:
  tls:
    mode: transitionToTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

Une fois tous les clients mis à jour et vérifiés, changez mode à requireTLS et redémarrez.

3. Oplog de réplication trop petit

Symptômes :

• Les secondaires prennent du retard pendant les pics d'écriture
• Rollbacks lors des élections

Vérification de la fenêtre :

rs.printReplicationInfo()

Si la fenêtre de l'oplog n'est que de quelques minutes à une heure sur un système chargé, redimensionnez-le.

Redimensionnement sûr (un membre à la fois) :

• Choisissez un secondaire, assurez-vous qu'il est sain et à jour
• Redimensionnez sur ce nœud, observez l'état stable, répétez pour les autres secondaires, puis le primaire

Commande sur le nœud choisi (exemple pour 10 Go) :

use admin
db.adminCommand({ replSetResizeOplog: 1, size: 10240 })
rs.printReplicationInfo()

Assurez-vous que la fenêtre de l'oplog grandit comme prévu et que la réplication reste saine.

4. Write concern risqué et journalisation mal assortie

Symptômes :

• Utiliser w:1 et j: false sur des écritures critiques risque des données acquittées mais perdues en cas de coupure de courant
• Défauts incohérents entre les services

Vérification du RW concern par défaut actuel :

use admin
db.adminCommand({ getDefaultRWConcern: 1 })

Défaut cluster-wide plus sûr :

use admin
db.adminCommand({
  setDefaultRWConcern: 1,
  defaultWriteConcern: { w: 'majority', j: true, wtimeout: 0 }
})

Exemple de surcharge applicative (Node.js) :

const client = await MongoClient.connect(uri, {
  writeConcern: { w: 'majority', j: true, wtimeoutMS: 5000 }
});

5. Cache WiredTiger mal dimensionné

Symptômes :

• Trop petit : page faults élevés, pression d'éviction du cache, requêtes lentes
• Trop grand : pression mémoire sur l'OS et risque d'OOM

Vérification :

use admin
db.serverStatus().wiredTiger.cache // examinez bytes currently in cache et stats d'éviction

Approche sûre :

• Commencez avec le dimensionnement par défaut du cache
• Si personnalisation, choisissez une valeur conservatrice et observez

Exemple de config (pour un serveur de 32 Go) :

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 14

Redémarrez, puis observez les métriques mémoire et d'éviction pendant plusieurs heures.

6. Journalisation désactivée

Symptômes :

• Écritures perçues plus rapides mais risque de perte de données au crash

Vérification :

use admin
db.serverStatus().wiredTiger.transaction // vérifiez les stats de durabilité

Config plus sûre :

storage:
  journal:
    enabled: true

Redémarrez pour appliquer.

7. Limites de descripteurs de fichiers trop basses

Symptômes :

• Pics de connexions qui échouent avec EMFILE (Too many open files)

Vérification des limites :

cat /proc/$(pidof mongod)/limits | grep 'open files'

Augmentation via override systemd :

sudo systemctl edit mongod

Ajoutez :

[Service]
LimitNOFILE=64000

Puis :

sudo systemctl daemon-reload && sudo systemctl restart mongod

8. Priorités de l'ensemble de réplicas et membres hidden mal configurés

Symptômes :

• Élections qui choisissent un primaire mal placé
• Membres hidden ou delayed qui deviennent éligibles par inadvertance

Vérification et correction :

var cfg = rs.conf()
// Examinez cfg.members[*].priority, .hidden, .votes
// Exemple : assurez-vous que le secondaire analytique est hidden et non-voting
cfg.members[2].hidden = true
cfg.members[2].priority = 0
cfg.members[2].votes = 0
rs.reconfig(cfg)

Appliquez un seul ensemble de changements logiques à la fois et confirmez la nouvelle config avec rs.conf().

Tableau de référence rapide

Vérification et diagnostics

Après chaque changement, vérifiez avec des signaux simples et observables. Privilégiez les vérifications qui prouvent l'état visé et détectent les régressions.

Sécurité et accès

• Depuis un hôte non approuvé, la connexion doit échouer :

mongosh 'mongodb://MONGO_HOST:27017' --eval 'db.runCommand({ping:1})'
# Attendez une erreur d'authentification ou TLS quand bloqué

• Depuis un compte admin, l'admin de base fonctionne :

mongosh 'mongodb://siteRootAdmin:***@MONGO_HOST/admin?authSource=admin' --eval 'db.runCommand({ping:1})'

• La négociation TLS réussit :

openssl s_client -connect MONGO_HOST:27017 -tls1_2 -servername MONGO_HOST < /dev/null 2>/dev/null | head -5

Réplication et durabilité

• Réplication saine :

rs.status().members.map(m => ({name: m.name, stateStr: m.stateStr, optime: m.optimeDate}))
rs.printSecondaryReplicationInfo()

• Fenêtre d'oplog raisonnable pour votre volume d'écriture :

rs.printReplicationInfo()

• Write concern par défaut défini :

use admin
db.adminCommand({ getDefaultRWConcern: 1 })

Performance et ressources

• Cache et éviction stables :

var c = db.serverStatus().wiredTiger.cache; ({usedGB:(c['bytes currently in the cache']/(1024**3)).toFixed(1), evictions: c['eviction server evicted pages']})

• Descripteurs de fichiers :

cat /proc/$(pidof mongod)/limits | grep 'open files'

• Logs calmes sur les avertissements après redémarrage :

sudo journalctl -u mongod -n 200 --no-pager | egrep -i 'error|warn|tls|auth|oplog'

Résultats attendus :

• Sécurité : tentatives non authentifiées bloquées ; authentifiées réussies ; TLS négocié quand requis
• Réplication : tous membres SECONDARY ou PRIMARY comme prévu ; peu ou pas de lag de réplication ; fenêtre d'oplog dimensionnée pour dépasser confortablement le pic de délai de réplication
• Durabilité : write concern par défaut montre majority + j: true pour charges critiques
• Ressources : utilisation du cache maîtrisée ; marge mémoire système préservée ; NOFILE assez haut pour éviter les erreurs EMFILE

Modes de défaillance et récupération

Planifiez les façons dont les changements peuvent échouer et scriptez le retour arrière.

Bind IP et auth

• Défaillance : activer l'auth avant de créer un utilisateur admin mène au verrouillage
• Récupération : annulez le dernier changement de config et redémarrez ; si nécessaire pendant la maintenance, désactivez temporairement l'autorisation dans la config, redémarrez sur un réseau isolé, créez l'utilisateur admin, puis réactivez l'autorisation et redémarrez

Changements de mode TLS

• Défaillance : passage direct à requireTLS coupe les clients legacy
• Récupération : revenez à transitionToTLS, mettez à jour les clients, puis repassez à requireTLS

Redimensionnement de l'oplog

• Défaillance : réduction trop forte cause le retard des secondaires et nécessite une sync initiale
• Récupération : augmentez la taille de l'oplog et laissez rattraper ; si un secondaire sort de la fenêtre d'oplog, effectuez une sync initiale sur ce membre

Write concern par défaut

• Défaillance : plus de timeouts d'écriture après avoir augmenté la durabilité
• Récupération : baissez wtimeout, envisagez de passer de majority à un w plus bas pour chemins non critiques, ou annulez le défaut avec :

use admin
db.adminCommand({ setDefaultRWConcern: 1, defaultWriteConcern: { w: 1, j: false, wtimeout: 0 } })

Puis ajustez par collection ou par chemin d'API dans le driver client.

Cache WiredTiger

• Défaillance : surdimensionnement déclenche OOM ou swapping
• Récupération : revenez au cacheSizeGB précédent, redémarrez, et surveillez la pression mémoire

Descripteurs de fichiers

• Défaillance : le service ne démarre pas après un mauvais override systemd
• Récupération : supprimez ou corrigez le fichier d'override, lancez systemctl daemon-reload, puis redémarrez

Reconfig de l'ensemble de réplicas

• Défaillance : mettre toutes les priorités à 0 empêche l'élection d'un primaire
• Récupération : corrigez la config et lancez rs.reconfig(cfg) depuis un nœud avec quorum ; si le cluster est bloqué, consultez soigneusement le processus de reconfig avec une majorité de nœuds en ligne

Toujours vérifier la récupération

• Confirmez que le service démarre proprement
• Confirmez les modes auth/TLS attendus
• Confirmez la santé de la réplication
• Confirmez que les lectures/écritures applicatives fonctionnent dans les SLO

Liste de contrôle opérationnelle

Utilisez cette liste courte et reproductible pour le travail de configuration.

Planifier

• Définissez le changement, la portée et les signaux de succès mesurables
• Capturez l'inventaire : version, topologie, config actuelle
• Prenez une sauvegarde testée des données et du fichier de config
• Choisissez un nœud pilote (préférez un secondaire)

Implémenter (un ensemble de changements à la fois)

• Préparez le diff de config exact et les commandes
• Appliquez au nœud pilote
• Redémarrez seulement si requis par le paramètre
• Observez les logs et métriques pendant au moins 15-30 minutes ou assez longtemps pour couvrir le comportement de pointe

Vérifier

• Lancez les commandes de vérification pour sécurité, réplication et ressources
• Comparez les métriques à la ligne de base et aux critères de succès
• Si le pilote est stable, déployez séquentiellement sur les nœuds restants

Retour arrière

• Gardez une copie de la config précédente par nœud
• Connaissez la commande unique pour annuler le changement (ex: setDefaultRWConcern, restaurer bindIp)
• Vérifiez la santé du service et les SLO applicatifs après retour arrière

Documenter

• Mettez à jour les runbooks et docs avec la config finale et la justification
• Notez les preuves de vérification et les suivis nécessaires

Tableau d'impact des changements

Conclusion

MongoDB répond bien aux changements de configuration délibérés et observables. Commencez par un pilote étroit, vérifiez d'une manière qui reflète votre charge réelle, et gardez le retour arrière simple. Utilisez les vérifications et exemples ici pour durcir la sécurité, améliorer la durabilité et réduire le bruit opérationnel évitable. À mesure que vous adoptez les changements, documentez les diffs exacts, les commandes et les signaux qui prouvent le succès pour que le prochain changement soit encore plus sûr et rapide.