Exploitation courante et scénarios de panne MongoDB (replica set et sharded cluster)

Pas une installation : runbook par scénario pour exploiter au quotidien un replica set et un sharded cluster MongoDB déjà installés, et les remettre en état quand ils tombent en panne. Contrôle de santé, ajout/retrait de membres, membre priority/hidden/delayed, remplacement d'un arbiter par un membre porteur de données, resynchronisation d'un membre en retard, force reconfig après perte de la majorité, stepDown planifié, taille de l'oplog, FCV ; ajout/retrait de shards, balancer, jumbo chunks et reshardCollection. Si vous ne savez pas quoi faire, commencez par le contrôle de santé ; la restauration depuis une sauvegarde, la sécurité et les montées de version majeure sont traitées dans des guides MongoDB distincts.

Topologie: Replica set (3 membres ou plus) ou sharded cluster (config server + replica sets des shards + mongos)

Scénarios

• Contrôle de santé : membres, retard, fenêtre d'oplog (shards et balancer en sharded) — Lecture seule : état des membres, retard de réplication, fenêtre d'oplog, configuration ; sur un sharded cluster, liste des shards, balancer et répartition des chunks. Commencez ici si vous ne savez pas quoi faire.
• Ajouter un nouveau membre au replica set (initial sync) — Un nouveau serveur est prêt (même version, keyfile, replSetName) ; il est ajouté avec priority 0 / votes 0, puis reçoit son vote et sa priorité une fois l'initial sync terminée et l'état SECONDARY atteint. Aucune interruption.
• Retirer un membre du replica set — Le serveur est mis hors service ou définitivement perdu : le membre est retiré de la configuration et on vérifie que les votes restants forment toujours une majorité. S'il est primary, faites d'abord un stepDown.
• Modifier le rôle d'un membre : priority, membre hidden, membre delayed (différé) — Modifier la priorité d'un membre pour devenir primary, en faire un membre caché (hidden) pour le reporting/la sauvegarde ou un membre différé (delayed) contre les suppressions accidentelles, ou le remettre à l'état normal.
• Remplacer l'arbiter par un membre porteur de données (PSA → PSS) — Replica set primary + secondary + arbiter : quand un membre de données tombe, les écritures majority et la pression sur le cache deviennent un problème. Un nouveau membre de données est ajouté et l'arbiter est retiré.
• Resynchroniser un membre en retard ou corrompu (resync) — Le membre est bloqué en RECOVERING et affiche 'too stale to catch up', ou ses fichiers de données sont corrompus : le répertoire de données du membre est vidé et il est resynchronisé de zéro par une initial sync. Les autres membres continuent de fonctionner.
• Perte de la majorité : reconfigurer de force avec les membres restants (force reconfig) — La plupart des membres sont définitivement perdus (perte d'un site/de serveurs) et les survivants ne peuvent pas élire de primary : rs.reconfig(cfg, {force: true}) avec les membres restants. Dernier recours ; mal utilisé, risque de perte de données et de split brain.
• Changer de primary de façon planifiée (rs.stepDown, désigner un membre précis comme primary) — Une maintenance/un patch est prévu sur le serveur primary : le primary se retire et un secondary à jour devient primary. L'application peut recevoir des erreurs d'écriture pendant quelques secondes.
• Modifier la taille de l'oplog (replSetResizeOplog) — La fenêtre d'oplog est courte : les secondaries deviennent 'too stale' après une maintenance, la sauvegarde ne parvient pas à capturer l'oplog, ou elle ne suffit pas pour une restauration à un instant donné. On l'agrandit sur chaque membre sans interruption.
• Vérifier et finaliser la Feature Compatibility Version (FCV) — Après une montée de version, la FCV est restée à l'ancienne version ou les membres n'ont pas la même version : la version binaire et la FCV de chaque membre sont vérifiées, puis la FCV est portée à la nouvelle version.
• Ajouter un shard au cluster (sh.addShard) — La capacité ne suffit plus : un nouveau replica set de shard (shardsvr) a été monté et est ajouté au cluster ; le balancer y migre les chunks progressivement.
• Retirer un shard (removeShard : drain et movePrimary) — Un shard est mis hors service : ses chunks sont vidés vers les autres shards (drain), les bases dont il est le primary shard sont déplacées (movePrimary), puis il est retiré du cluster.
• Balancer : fenêtre horaire, arrêt / démarrage, désactivation par collection — Les migrations de chunks chargent le système aux heures de pointe, elles doivent s'arrêter pendant une maintenance/sauvegarde, ou une collection donnée ne doit pas être équilibrée.
• Répartition déséquilibrée ou jumbo chunks (diagnostic et correction) — Un shard est bien plus rempli que les autres, le balancer ne migre pas, des chunks sont marqués 'jumbo' ou moveChunk échoue : on examine la répartition, les jumbo chunks et les erreurs du balancer.
• Changer la shard key (reshardCollection) — La shard key actuelle provoque un shard chaud, des jumbo chunks ou des requêtes scatter-gather : la collection est redistribuée en ligne avec une nouvelle shard key (5.0+). À la fin, les écritures sont bloquées environ 2 s.

Avant de commencer

• mongosh est installé sur le serveur d'administration, qui dispose de la résolution de noms et de l'accès réseau …au mongos (…)…à tous les membres (…)…. Les noms utilisés dans la connexion doivent correspondre aux noms des membres dans rs.conf().
• Vous disposez du mot de passe de l'utilisateur … ; son rôle est root ou au minimum clusterAdmin + readAnyDatabase.… La connexion directe à un replica set de shard ou de config server nécessite l'administrateur local du shard (créé dans le guide mongo-sharded).…
• Une demande de changement / fenêtre de maintenance est ouverte et l'équipe applicative est prévenue. Les opérations de reconfig, stepDown et sur les shards peuvent provoquer une élection ou un délai de routage de quelques secondes.
• Le nouveau membre … a été préparé selon les phases système d'exploitation, installation, keyfile et configuration du guide d'installation du replica set : même version de MongoDB (…), même keyfile, replication.replSetName: …, mongod démarré mais rs.initiate NON exécuté. La résolution de noms et l'accès réseau fonctionnent dans les deux sens avec les autres membres ; le disque de données dispose d'au moins autant d'espace libre que les données actuelles.
• Pendant l'initial sync, toutes les données sont réécrites sur le disque du membre… ; l'ancien répertoire étant mis de côté, il faut un espace libre égal au double de la taille des données…. Les membres restants conservent la majorité, et la fenêtre d'oplog du membre source est plus longue que la durée prévue de l'initial sync.

Phases du guide

• État : membres, retard et oplog (lecture seule) — Afficher l'état et le retard des membres · Afficher la configuration (priority, votes, hidden, delay) · Interpréter le résultat et choisir le bon scénario
• État : shards, balancer et répartition des chunks (lecture seule) — Afficher le résumé du cluster · Répartition des chunks et jumbo chunks · Vérifier l'état des replica sets des shards
• 1. Diagnostic : le nouveau membre est-il prêt ? — Vérifier le service et la version du nouveau membre · Voir l'état du set actuel et la taille des données · Vérifier l'accès au nouveau membre
• 2. Filet de sécurité — Sauvegarder la configuration actuelle du replica set
• 3. Application : ajouter le membre et attendre sa synchronisation — Ajouter le membre avec priority 0 / votes 0 · Attendre la fin de l'initial sync · Donner au membre un vote et une priorité
• 4. Vérification et suite — Vérifier l'état · Mettre à jour les chaînes de connexion des applications et la supervision
• 1. Diagnostic : le membre à retirer est-il le primary, la majorité est-elle conservée ? — Déterminer le rôle du membre et le nombre de votes restants
• 2. Filet de sécurité — Sauvegarder la configuration actuelle du replica set
• 3. Application : retirer le membre — Retirer le membre de la configuration (rs.remove) · Arrêter mongod sur le serveur retiré
• 4. Vérification et suite — Vérifier l'état · Mettre à jour les chaînes de connexion, la supervision et le firewall
• 1. Diagnostic — Voir les paramètres actuels du membre et la fenêtre d'oplog
• 2. Filet de sécurité — Sauvegarder la configuration actuelle du replica set
• 3. Application — Modifier le paramètre du membre (rs.reconfig)
• 4. Vérification — Vérifier le résultat
• 1. Diagnostic : arbiter et nouveau membre — Voir l'arbiter et le write concern · Vérifier que le nouveau membre est prêt
• 2. Filet de sécurité — Sauvegarder la configuration actuelle du replica set
• 3. Application : ajouter le membre de données, retirer l'arbiter — Ajouter le nouveau membre avec priority 0 / votes 0 · Attendre la fin de l'initial sync · Donner au nouveau membre un vote et une priorité · Retirer l'arbiter · Arrêter mongod sur le serveur de l'arbiter
• 4. Vérification et suite — Vérifier l'état et le write concern
• 1. Diagnostic : le membre doit-il vraiment être resynchronisé ? — Voir l'état et le dernier message du membre · Voir l'erreur dans le log du membre
• 2. Filet de sécurité — Sauvegarder la configuration actuelle du replica set
• 3. Application : vider le répertoire de données et lancer l'initial sync — Arrêter mongod · …Mettre le répertoire de données de côté…Vider le répertoire de données… · Démarrer mongod (l'initial sync démarre) · Attendre la fin de l'initial sync
• 4. Vérification et suite — Vérifier l'état · Supprimer l'ancien répertoire de données
• 1. Diagnostic : la majorité est-elle vraiment perdue définitivement ? — Voir l'état et les optimes depuis un membre survivant · Vérifier que les membres perdus sont arrêtés
• 2. Filet de sécurité — Sauvegarder la configuration du membre survivant
• 3. Application : force reconfig — Reconfigurer de force avec les seuls membres survivants · Vérifier qu'un primary a été élu
• 4. Vérification et suite — Tester une écriture majority · Réintégrer les membres perdus et corriger la cause racine
• 1. Diagnostic : les secondaries sont-ils à jour ? — Voir le primary et les retards
• 2. Application — Geler les autres secondaries (pour que la cible soit élue) · Faire se retirer le primary (rs.stepDown)
• 3. Vérification — Vérifier le nouvel état
• 1. Diagnostic : taille et fenêtre actuelles de l'oplog — Taille et fenêtre de l'oplog sur chaque membre