## 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:REDACTED@10.0.0.10,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.