Liste de contrôle des opérations MongoDB en production avec exemples pratiques

Introduction

Exécuter MongoDB en production devient simple si vous standardisez quelques décisions et automatisez les tâches récurrentes. Ce guide propose une checklist pratique avec des exemples copier‑coller pour :

Configuration et jeux de réplication
Durcissement de la sécurité
Observabilité et dépannage
Sauvegardes et restaurations fiables
Routines de maintenance
Mises à niveau et déploiements
Pièges courants à éviter

Les exemples utilisent mongosh, systemd et Node.js/Express pour une adaptation rapide.

---

Aperçu du flux de travail

Un flux clair et reproductible maintient la stabilité en production :

Planifier

Définir les SLO (Service Level Objective) : latence p95, disponibilité, RPO (Recovery Point Objective) / RTO (Recovery Time Objective).
Capacité : ensemble de travail vs RAM, IOPS, taux de croissance.

Configurer

Appliquer un mongod.conf de base et une unité systemd.
Utiliser un jeu de réplication à 3 nœuds minimum.

Sécuriser

Activer l'autorisation, créer des utilisateurs RBAC, imposer TLS.
Restreindre l'accès réseau et faire tourner les secrets.

Connecter les applications

Paramètres de pilote sûrs : connexions en pool, timeouts, écritures majority.

Observer

Tableaux de bord et alertes : lag de réplication, cache, opérations lentes, disque.

Protéger les données

Sauvegardes logiques + snapshots. Tester les restaurations.

Maintenir

Vérifications de santé, revue d'index, rotation des logs, validation ciblée.

Mettre à niveau

Mises à niveau progressives avec sauvegardes et gating de la version de compatibilité des fonctionnalités (FCV - Feature Compatibility Version).

Itérer

Commencer petit, mesurer, étendre.

---

Configuration de base

Utilisez une configuration cohérente, versionnée et des réglages OS.

Exemple /etc/mongod.conf :

storage:
  dbPath: /var/lib/mongo
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4
net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.10
security:
  authorization: enabled
replication:
  replSetName: rs0
setParameter:
  diagnosticDataCollectionEnabled: true

Exemple d'unité systemd /etc/systemd/system/mongod.service :

[Unit]
Description=MongoDB Database Server
After=network.target

[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
LimitNOFILE=64000
Restart=on-failure
Type=notify

[Install]
WantedBy=multi-user.target

Initialisation du jeu de réplication (remplacez les hôtes par vos IPs réelles) :

mongosh --host 10.0.0.10 --eval 'rs.initiate({_id:"rs0", members:[{_id:0, host:"10.0.0.10:27017"},{_id:1, host:"10.0.0.11:27017"},{_id:2, host:"10.0.0.12:27017"}]})'

Notes OS et système de fichiers

Assurez vm.swappiness=1 pour les nœuds de base de données (ajoutez à /etc/sysctl.d/99-mongodb.conf et lancez sysctl --system).
Utilisez XFS ou ext4 avec l'option de montage noatime.
Prévoyez une marge d'IOPS ; évitez les voisins bruyants sur stockage partagé.
Réglez vm.max_map_count=262144 et les descripteurs de fichiers (ulimit -n 64000) suffisamment hauts pour la charge de travail.

---

Durcissement de la sécurité

Activer l'authentification et créer des utilisateurs

mongosh --host primary-host <<'EOF'
use admin
db.createUser({
  user: "siteRootAdmin",
  pwd: "REDACTED-STRONG-PASSWORD",
  roles: [ { role: "root", db: "admin" } ]
})
use appdb
db.createUser({
  user: "appUser",
  pwd: "REDACTED-App-Pass",
  roles: [ { role: "readWrite", db: "appdb" } ]
})
EOF

Imposer TLS

Dans mongod.conf :

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongo/server.pem
    CAFile: /etc/ssl/mongo/ca.pem

Contrôles réseau

Lier uniquement aux IPs explicites (pas 0.0.0.0).
Restreindre l'entrée aux sous‑réseaux applicatifs et d'administration via groupes de sécurité ou règles pare‑feu.
Utiliser des groupes de sécurité distincts pour le trafic client (port 27017) et le trafic de réplication si possible.

Secrets et clés

Faire tourner les mots de passe et certificats TLS tous les 90 jours.
Éviter de stocker les identifiants dans les dépôts d'applications ; utiliser des variables d'environnement ou un gestionnaire de secrets (ex. HashiCorp Vault, AWS Secrets Manager).

---

Observabilité et surveillance

Signaux clés à surveiller

Réplication : rs.status(), lag de réplication < votre RPO (ex. < 10 secondes).
Cache WiredTiger : cache utilisé vs configuré ; évictions en hausse avec latence élevée signalent une pression mémoire.
Connexions : pics pouvant indiquer fuites ou tempêtes.
Mix d'opérations : taux insert/update/delete/query.
Files d'attente et verrous : lecteurs/écrivains actifs, pourcentage de verrou lors des pics.
Disque : IOPS, latence, espace libre, durées de checkpoint.
Requêtes lentes : capturer et corriger les principaux contrevenants.

Outils rapides

# Compteurs haut niveau
mongostat --rowcount 5
# Activité par collection
mongotop 5

Profilage côté serveur (à utiliser avec parcimonie)

// Dans mongosh, activer le seuil d'opération lente à 200 ms
db.setProfilingLevel(1, { slowms: 200 })
// Plus tard, désactiver
db.setProfilingLevel(0)

Suggestions d'alertes

Lag de réplication > 10 s (ajuster selon votre RPO).
Cache dirty/utilisé approchant 90 % avec latence en hausse.
Espace disque libre < 15 % ou système de fichiers presque plein.
Connexions près de la limite du pool.
Fenêtre d'oplog < exigence de fenêtre de restauration.

Journalisation

Conserver les fichiers de log sur un volume distinct des données si possible.
Rotater avec la commande logRotate et logrotate système (quotidien, conserver 14 jours, compresser).

---

Sauvegardes et restauration

Combinez stratégies logiques et par snapshot.

Dumps logiques pour la portabilité

# Dump logique conscient du jeu de réplication avec oplog pour fenêtre PITR
mongodump \
  --uri "mongodb://appUser:REDACTED@rs0-1,rs0-2,rs0-3/admin?replicaSet=rs0" \
  --out /backups/$(date +%F) \
  --oplog

Test de restauration :

mongorestore \
  --uri "mongodb://restoreUser:REDACTED@localhost:27017/admin" \
  --dir /backups/2026-07-10 \
  --oplogReplay \
  --drop

Snapshots système de fichiers pour la rapidité (sur un secondaire)

# Verrouiller le secondaire pour un snapshot propre
mongosh --host rs0/secondary-host --eval 'db.fsyncLock()'
# Créer et monter un snapshot LVM (exemple ; adaptez à votre stockage)
lvcreate -L 20G -s -n mongo-data-snap /dev/vg0/mongo-data
mount -o ro /dev/vg0/mongo-data-snap /mnt/mongo-snap
# Copier le snapshot hors hôte
rsync -aH --numeric-ids /mnt/mongo-snap/ /backup-target/mongo/
# Nettoyage
umount /mnt/mongo-snap
lvremove -f /dev/vg0/mongo-data-snap
mongosh --host rs0/secondary-host --eval 'db.fsyncUnlock()'

Checklist de politique de sauvegarde

Définir les cibles RPO et RTO.
Stocker les sauvegardes hors site et chiffrées au repos.
Conserver au moins une sauvegarde complète récente vérifiée par restauration.
Automatiser les tests de restauration (ex. chaque nuit dans un environnement jetable) et valider les compteurs et checksums.

---

Maintenance et opérations courantes

Hebdomadaire

Revue des requêtes lentes ; ajouter ou ajuster les index.
Vérifier les tendances de lag de réplication et la fenêtre d'oplog.
Confirmer la réussite du job de sauvegarde et l'horodatage du dernier test de restauration.

Quotidien

Inspecter les tableaux de bord pour pics d'erreurs et croissance du stockage.
Rotater les logs si nécessaire.

Mensuel

Valider un sous‑ensemble de collections :

// Validation d'échantillon ; éviter une validation complète en période de pointe
db.getCollectionNames().slice(0,5).forEach(c => printjson(db.getCollection(c).validate({ full: false })))

Soin des index

Privilégier les index composés correspondant aux motifs de requête.
Supprimer les index inutilisés après vérification via $indexStats ou db.collection.aggregate([{$indexStats:{}}]).

Sécurité opérationnelle

Éviter d'exécuter compact ou une validation complète en période de pointe.
Planifier les tâches lourdes avec limitation de débit (ex. rs.syncFrom() pour throttling de la synchronisation initiale).

---

Mises à niveau et déploiements

Préparation

Lire les notes de version pour les changements cassants.
Vérifier la compatibilité des pilotes avec la version cible.
Sauvegarder et tester une restauration.

Mise à niveau progressive (jeu de réplication)

Mettre à niveau un secondaire

systemctl stop mongod
# ... mettre à jour les binaires via votre gestionnaire de paquets ...
systemctl start mongod
# Attendre l'état SECONDARY et la réplication complète

Répéter pour tous les secondaires

Rétrograder le primaire et le mettre à niveau

mongosh --host primary --eval 'rs.stepDown(60)'
# Mettre à niveau et redémarrer le nœud primaire

Version de compatibilité des fonctionnalités (FCV - Feature Compatibility Version) après la mise à niveau de tous les nœuds

// Définir la FCV sur la nouvelle version après vérifications de stabilité
db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })

Observabilité pendant la mise à niveau

Surveiller le lag de réplication, les élections et les erreurs client.
Faire une pause de 5 à 10 minutes entre chaque nœud pour assurer la stabilité.

Plan de retour arrière

Si les erreurs augmentent, arrêter et rétrograder les nœuds mis à niveau vers la version précédente via le gestionnaire de paquets.
Maintenir la FCV à la version précédente jusqu'à la fin du retour arrière.

---

Plan pilote local

Commencer petit, mesurer, puis étendre.

Périmètre

Un jeu de réplication de test à 3 nœuds (conteneurs ou VMs).
Une API Express avec 2‑3 endpoints.
Tableaux de bord minimaux pour les métriques principales.
Un job de sauvegarde et un test de restauration automatisé.

Étapes

Provisionner

Lancer 3 nœuds et appliquer le mongod.conf de base et systemd.
Initialiser le jeu de réplication.

Sécuriser

Créer les utilisateurs admin et app, activer TLS.

Connecter une API Express

// app.js
const express = require('express');
const { MongoClient } = require('mongodb');

const uri = 'mongodb://appUser:[email protected],10.0.0.11,10.0.0.12/appdb?replicaSet=rs0&tls=true';
const client = new MongoClient(uri, {
  maxPoolSize: 50,
  minPoolSize: 5,
  waitQueueTimeoutMS: 5000,
  serverSelectionTimeoutMS: 5000,
  socketTimeoutMS: 20000,
  retryWrites: true,
  w: 'majority',
  wtimeoutMS: 5000
});

const app = express();
app.use(express.json());

app.get('/healthz', async (req, res) => {
  try {
    await client.db('admin').command({ ping: 1 });
    res.status(200).send('ok');
  } catch (e) {
    res.status(500).send('not-ok');
  }
});

app.post('/items', async (req, res) => {
  try {
    const r = await client.db('appdb').collection('items').insertOne(req.body);
    res.status(201).json({ id: r.insertedId });
  } catch (e) {
    res.status(500).json({ error: 'insert_failed' });
  }
});

(async () => {
  await client.connect();
  app.listen(3000, () => console.log('API on :3000'));
})();

Sauvegarder et restaurer

Exécuter mongodump avec --oplog.
Restaurer dans un MongoDB jetable et lancer une validation rapide des données.

Exercices de panne

Tuer le primaire et confirmer que le basculement s'achève dans la cible.

Critères de réussite du pilote

Latence p95 de l'API dans la cible sous charge nominale.
Temps de basculement automatique dans la cible (ex. < 30 secondes).
Restauration réussie dans le RTO et données validées.

---

Pièges courants en production

Absence d'authentification ou de TLS : activer l'autorisation et imposer TLS.
Déploiements mono‑nœud : utiliser au moins 3 nœuds pour la haute disponibilité.
Écritures non sûres : éviter w:1 sans journalisation ; privilégier w: "majority" et écritures journalisées.
Index manquants : requêtes lentes et CPU élevé ; ajouter des index sur les champs de filtre et de tri.
Documents volumineux : limite de 16 Mo par document ; revoir le schéma ou utiliser GridFS si nécessaire.
Primaire surchargé : toutes les lectures sur le primaire ; envisager des préférences de lecture adaptées pour les charges de lecture intensives.
Oplog trop petit : la réplication prend du retard et la fenêtre de restauration point‑in‑time se réduit ; dimensionner l'oplog selon le taux d'écriture (ex. 10‑20 % du volume de données).
Sauvegardes non testées : une sauvegarde non restaurée n'est pas prouvée ; planifier des tests de restauration.
Croissance non maîtrisée : index TTL pour données éphémères ; archiver les anciennes collections.
Mises à niveau sans planification de la FCV : définir et vérifier la compatibilité des fonctionnalités au bon moment.

Vérifications rapides

# Auth activée ?
mongosh --eval 'db.runCommand({ connectionStatus: 1 })'
# Réplication saine ?
mongosh --eval 'rs.status()'
# Opérations lentes ?
mongosh --eval 'db.getSiblingDB("admin\)).system.profile.find().sort({ts:-1}).limit(5)'

---

Conclusion

Vous disposez maintenant d'une checklist pratique de bout en bout pour exploiter MongoDB en production : configuration durcie, sécurité forte, observabilité actionnable, sauvegardes fiables avec restaurations testées, routines de maintenance sûres et mises à niveau contrôlées. Commencez par le pilote local, mesurez les temps de basculement et de restauration, corrigez les écarts, puis étendez les mêmes patterns vers la pré‑production et la production.