7.2.9.5.2. Procédure de conversion d’un noeud Arbiter en Secondary¶

Attention

Cette opération modifie la topologie du cluster MongoDB. Avant de commencer, assurez-vous d’avoir une sauvegarde récente de vos bases de données.

Note

Cette opération peut être effectuée sans interruption de service, mais une baisse de performances temporaire est à prévoir durant la synchronisation du nouveau noeud.

7.2.9.5.2.1. Retrait de l’Arbiter du replicaset¶

Prudence

Ces commandes doivent être exécutées sur le noeud Primary actuel du replicaset concerné.

7.2.9.5.2.1.1. 1. Connexion au primary¶

Identifiez et connectez-vous au noeud Primary du shard concerné :

# Exemple de connexion
mongosh --host <IP_primary> --port <mongod_port> -u vitamdb-localadmin -p

Note

Pour les anciennes versions de MongoDB (< 5.0), soit Vitam < V6.rc, vous devrez utiliser la commande mongo au lieu de mongosh.

7.2.9.5.2.1.2. 2. Vérification de la configuration actuelle¶

Affichez la configuration du replicaset pour identifier le nom du membre Arbiter :

shard0 [direct: primary] test> rs.conf()

Vérifiez que le noeud à modifier est bien configuré comme arbiterOnly: true.

Exemple de sortie attendue :

{
  "_id" : "shard0",
  "members" : [
    { "_id" : 0, "host" : "mongo1:27019" },
    { "_id" : 1, "host" : "mongo2:27019" },
    { "_id" : 2, "host" : "mongo3:27019", "arbiterOnly" : true }
  ]
}

7.2.9.5.2.1.3. 3. Suppression de l’Arbiter¶

Supprimez le noeud Arbiter du replicaset en utilisant son host (ici mongo3:27019) :

shard0 [direct: primary] test> rs.remove("mongo3:27019")

7.2.9.5.2.1.4. 4. Validation du retrait¶

Vérifiez que le noeud a bien disparu de la liste des membres :

shard0 [direct: primary] test> rs.status()

7.2.9.5.2.2. Réinitialisation du noeud (ancien Arbiter)¶

Avertissement

Les étapes suivantes doivent être effectuées sur la machine hébergeant le noeud Arbiter que vous venez de retirer (ex: mongo3).

7.2.9.5.2.2.1. 1. Arrêt du service¶

Arrêtez le service MongoDB (vitam-mongod) :

systemctl stop vitam-mongod

7.2.9.5.2.2.2. 2. Purge des données (Action Destructive)¶

Danger

ATTENTION : Cette étape supprime définitivement les données présentes sur ce noeud.

Un noeud Arbiter ne contient pas de données applicatives, mais par précaution, nous déplaçons le répertoire plutôt que de le supprimer immédiatement. Si ce noeud contenait déjà des données (erreur de configuration précédente), assurez-vous qu’elles ne sont plus nécessaires.

Supprimez ou déplacez le contenu du répertoire de données (dbPath) pour que le noeud reparte de zéro afin de rejoindre le cluster en tant que Secondary:

# Déplacement de sécurité
mv /vitam/data/mongod/db/ /root/backup_arbiter_db_$(date +%F_%H-%M-%S)

# Recréation du dossier vide avec les bons droits
mkdir -p /vitam/data/mongod/db/
chown -R vitamdb:vitam /vitam/data/mongod/db/

7.2.9.5.2.2.3. 3. Redémarrage du service¶

Redémarrez le service vitam-mongod pour qu’il prenne en compte la purge des données :

systemctl start vitam-mongod

Le processus vitam-mongod va démarrer mais ne rejoindra pas le cluster automatiquement car il a été retiré de la configuration et ses données sont vides.

7.2.9.5.2.3. Intégration du nouveau noeud Secondary¶

Note

Retournez sur le terminal connecté au noeud Primary.

7.2.9.5.2.3.1. 1. Ajout du membre au Replicaset¶

Ajoutez le noeud (précédemment Arbiter, maintenant vide) en tant que membre classique. Il deviendra Secondary.

shard0 [direct: primary] test> rs.add("mongo3:27019")

7.2.9.5.2.3.2. 2. Suivi de la synchronisation (Initial Sync)¶

Le nouveau membre va passer par plusieurs états (STARTUP2, RECOVERING) pendant qu’il copie l’intégralité des données depuis un autre membre.

Important

Cette opération peut prendre du temps (plusieurs heures) selon le volume de données à synchroniser et la bande passante réseau.

Surveillez l’avancement avec :

shard0 [direct: primary] test> rs.status()

Attendez que le stateStr du nouveau membre soit SECONDARY.

7.2.9.5.2.4. Mise à jour de l’inventaire Ansible¶

Important

ETAPE CRITIQUE :

Une fois la manipulation manuelle terminée, vous DEVEZ mettre à jour votre inventaire Ansible pour refléter ce changement.

Dans votre fichier d’inventaire (ex: hosts.example) :

Localisez le noeud concerné.
Supprimez ou passez à false le paramètre mongo_arbiter.

Exemple :

# AVANT
[hosts_mongod_data]
mongo3 mongo_arbiter=true

# APRES
[hosts_mongod_data]
mongo3

Si vous oubliez cette étape, la prochaine exécution d’Ansible tentera de reconfigurer ce noeud en Arbiter ou échouera !

—

7.2.9.5.2.5. Cas particulier : Cluster Mongoc (Config Server)¶

D’après la configuration déployée par l’ansiblerie Vitam V5, les noeuds mongoc ont pu être déterminés comme Arbiter (à tort). Cependant, ils ne sont pas configurés en tant que tels dans le replicaset du cluster mongoc. Par conséquent, il n’est pas nécessaire de les retirer avant de les réintégrer en tant que Secondary.

Ainsi, le noeud ne devrait pas apparaître du tout dans la liste du rs.status(), vous pouvez directement l’ajouter via un rs.add en vous connectant au Primary du cluster mongoc :

configsvr:PRIMARY> rs.add("mongo3:27018")