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.

Retrait de l'Arbiter du replicaset
==================================

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

1. Connexion au primary
-----------------------

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

.. code-block:: bash

   # 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``.

2. Vérification de la configuration actuelle
--------------------------------------------

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

.. code-block:: javascript

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

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

Exemple de sortie attendue :

.. code-block:: json

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

3. Suppression de l'Arbiter
---------------------------

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

.. code-block:: javascript

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

4. Validation du retrait
------------------------

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

.. code-block:: javascript

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

Réinitialisation du noeud (ancien Arbiter)
==========================================

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

1. Arrêt du service
-------------------

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

.. code-block:: bash

   systemctl stop vitam-mongod

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**:

.. code-block:: bash

   # 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/

3. Redémarrage du service
-------------------------

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

.. code-block:: bash

   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.

Intégration du nouveau noeud Secondary
======================================

.. note::
   Retournez sur le terminal connecté au noeud **Primary**.

1. Ajout du membre au Replicaset
--------------------------------

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

.. code-block:: javascript

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

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 :

.. code-block:: javascript

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

Attendez que le ``stateStr`` du nouveau membre soit **SECONDARY**.

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``) :

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

   Exemple :

   .. code-block:: ini

      # 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 !

---

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`` :

.. code-block:: javascript

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