Checklist des opérations MongoDB en production avec exemples pratiques

Introduction

Exécuter MongoDB en production devient simple si vous standardisez quelques choix et automatisez les tâches répétitives. Cette MongoDB checklist propose des étapes actionnables avec des exemples copiables pour :

• Configuration et replica sets
• Renforcement de la sécurité
• Observabilité, monitoring et dépannage
• Sauvegardes et restaurations fiables
• Routines de maintenance
• Mises à niveau et déploiements progressifs
• Pièges courants à éviter

Les exemples utilisent mongosh, systemd, et Node.js/Express pour une adaptation rapide. Les termes clés comme MongoDB production, MongoDB operations, MongoDB checklist, MongoDB best practices et MongoDB maintenance sont conservés pour rester proches des usages de l'industrie.

---

Vue d'ensemble du workflow

Un workflow clair et répétable maintient la stabilité en production :

1. Planifier

• Définir des SLO : latence p95, disponibilité, RPO/RTO.
• Capacité : working set vs RAM, IOPS, taux de croissance.

1. Configurer

• Appliquer un mongod.conf de base et une unit systemd versionnés.
• Utiliser au minimum un replica set à 3 nœuds.

1. Sécuriser

• Activer l'autorisation, créer des utilisateurs RBAC, exiger TLS.
• Restreindre le réseau et faire tourner les secrets.

1. Connecter les applis

• Réglages sûrs du driver : pool, timeouts, écritures en majority.

1. Observer

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

1. Protéger les données

• Sauvegardes logiques + snapshots. S'entraîner à restaurer.

1. Maintenir

• Health checks, revues d'index, rotation des logs, validations ciblées.

1. Mettre à niveau

• Rolling upgrades avec sauvegardes et contrôle de compatibilité des fonctionnalités.

1. Itérer

• Démarrer petit, mesurer, étendre.

---

Configuration de base

Utilisez une configuration et des réglages OS cohérents, versionnés.

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 service 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 replica set (adapter les hôtes) :

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

• Réduire la swappiness sur les nœuds de base de données.
• Utiliser XFS ou ext4 avec noatime si pertinent.
• Prévoir une marge d'IOPS ; éviter les voisins bruyants.
• Régler vm.max_map_count et les descripteurs de fichiers selon la charge.

---

Renforcement de la sécurité

1. Activer l'auth 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

1. Exiger TLS

# Dans mongod.conf
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongo/server.pem
    CAFile: /etc/ssl/mongo/ca.pem

1. Contrôles réseau

• Se lier uniquement à des IP explicites.
• Restreindre l'ingress aux sous-réseaux applicatifs et admin.
• Séparer si possible le trafic client et celui de réplication.

1. Secrets et clés

• Faire tourner régulièrement les mots de passe et certificats TLS.
• Éviter les secrets dans les dépôts applicatifs ; préférer variables d'environnement ou un secrets manager.

---

Observabilité et monitoring

Signaux clés à surveiller

• Réplication : rs.status(), lag de réplication < votre RPO.
• Cache WiredTiger : utilisé vs configuré ; évictions + latence => pression mémoire.
• Connexions : pics = fuites ou orages.
• Mix d'opérations : taux insert/update/delete/query.
• Files et verrous : lecteurs/écrivains actifs, pourcentage de lock lors des pics.
• Disque : IOPS, latence, espace libre, temps de checkpoint.
• Requêtes lentes : capturer et corriger les pires cas.

Outils rapides

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

Profilage côté serveur (avec parcimonie)

// Dans mongosh, seuil des opérations lentes à 200ms
db.setProfilingLevel(1, { slowms: 200 })
// Plus tard, désactiver
db.setProfilingLevel(0)

Suggestions d'alertes

• Lag de réplication > 10s (à caler sur votre RPO).
• Cache dirty/used > ~90 % avec latence en hausse.
• Espace disque < 15 %.
• Connexions proches de la limite du pool.
• Fenêtre d'oplog < besoin de restauration.

Journalisation

• Isoler les logs du volume des données si possible.
• Faire la rotation avec logRotate et logrotate du système.

---

Sauvegardes et restauration

Combinez stratégies logiques et snapshots.

1. Dumps logiques pour la portabilité

# Dump logique conscient du replica set avec oplog pour une petite 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

1. Snapshots système de fichiers pour la vitesse (sur un secondaire)

# Quiescer le secondaire pour un snapshot propre
mongosh --host rs0/secondary-host --eval 'db.fsyncLock()'
# Créer et monter un snapshot LVM (exemple; adapter à 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 de l'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 des 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 comptes et checksums.

---

Maintenance et opérations de routine

Hebdomadaire

• Revoir les requêtes lentes ; ajouter/ajuster des index.
• Vérifier les tendances du lag de réplication et la fenêtre d'oplog.
• Confirmer le succès des jobs de sauvegarde et la date du dernier test de restauration.

Quotidien

• Surveiller les tableaux de bord : erreurs, latences, croissance du stockage.
• Faire tourner les logs si nécessaire.

Mensuel

• Valider un sous-ensemble de collections :

// Validation échantillonnée; éviter une validation complète en pic
db.getCollectionNames().slice(0,5).forEach(c => printjson(db.getCollection(c).validate({ full: false })))

Entretien des index

• Préférer des index composés alignés avec les patterns de requêtes.
• Supprimer les index inutilisés après vérification via les stats d'usage.

Sécurité opérationnelle

• Éviter compact ou validation complète en heures de pointe.
• Planifier les tâches lourdes avec limitation de débit.

---

Mises à niveau et déploiements

Préparer

• Lire les release notes et repérer les breaking changes.
• Vérifier la compatibilité des drivers.
• Sauvegarder et tester une restauration.

Rolling upgrade (replica set)

1. Mettre à niveau un secondaire

# Arrêter le secondaire, mettre à jour le binaire via votre gestionnaire de paquets, redémarrer
systemctl stop mongod
# ... mise à niveau des binaires ...
systemctl start mongod
# Attendre l'état SECONDARY et la pleine réplication

1. Répéter pour tous les secondaires

1. Forcer le stepdown du primaire et le mettre à niveau

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

1. Feature compatibility version (après mise à niveau de tous les nœuds)

// Régler la FCV sur la nouvelle version après stabilisation
db.adminCommand({ setFeatureCompatibilityVersion: 'X.Y' })

Observabilité durant la mise à niveau

• Surveiller le lag, les élections et les erreurs clients.
• Faire une pause entre les nœuds pour s'assurer de la stabilité.

Plan de rollback

• En cas d'erreurs, arrêter et revenir à la version précédente des nœuds.

---

Plan pilote local

Démarrez petit, mesurez, puis étendez.

Périmètre

• Un replica set de test à 3 nœuds (containers ou VMs).
• Une API Express avec 2-3 endpoints.
• Des dashboards minimaux pour les métriques clés.
• Un job de backup et un test de restauration automatisé.

Étapes

1. Provisionner

• Lancer 3 nœuds et appliquer le mongod.conf et le service systemd de base.
• Initier le replica set.

1. Sécuriser

• Créer les utilisateurs admin et appli, activer TLS.

1. 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'));
})();

1. Sauvegarder et restaurer

• Exécuter mongodump avec --oplog.
• Restaurer dans un MongoDB jetable et valider rapidement les données.

1. Exercices d'incident

• Tuer le primaire et confirmer un failover < SLO.
• Brider le disque pour simuler la pression I/O et observer les latences.

Critères de succès du pilote

• Latence p95 de l'API dans la cible en charge nominale.
• Temps de failover automatique dans la cible.
• Restauration réussie dans le RTO et données validées.

---

Pièges courants en production

• Pas d'auth ni TLS : activer l'autorisation et exiger TLS.
• Déploiement mono-nœud : au moins 3 nœuds pour la haute dispo.
• Écritures non sûres : éviter w:1 sans journal ; préférer w: 'majority' et écritures journalisées.
• Index manquants : requêtes lentes et CPU élevé ; indexer filtres et tris.
• Documents trop gros : respecter la limite de taille ; revoir le schéma ou GridFS.
• Primaire surchauffé : toutes les lectures sur le primaire ; adapter read preferences si besoin.
• Oplog trop petit : réplication en retard et fenêtre PITR réduite ; dimensionner selon le write rate.
• Backups non testés : planifier des tests de restauration réguliers.
• Croissance non maîtrisée : index TTL pour les données éphémères ; archiver l'historique.
• Mises à niveau sans plan FCV : définir et vérifier la FCV 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 récentes ?
mongosh --eval 'db.getSiblingDB("admin").system.profile.find().sort({ts:-1}).limit(5)'

---

Conclusion

Vous disposez désormais d'une checklist pratique et de bout en bout pour exécuter MongoDB en production : configuration durcie, sécurité robuste, monitoring actionnable, sauvegardes fiables avec restaurations testées, maintenance sûre et mises à niveau maîtrisées. Lancez le pilote local, mesurez les temps de bascule et de restauration, corrigez les écarts, puis déclinez ces mêmes patterns en staging et en production. Cette approche garde vos MongoDB best practices concrètes, auditables et faciles à répéter.