.. _reindexation_es:

Réindexation
############

Cette procédure consiste à réindexer le contenu des bases de données Elasticsearch-data (cluster d'indexation dédié aux données métier) en cas de perte ou d'inconsistance des données, à partir des informations présentes dans les bases de données MongoDB-data (replicaset MongoDB stockant les données métier de Vitam). Elle part du principe que le contenu des collections MongoDB-data n'a pas été altéré.

Le processus de réindexation se charge aussi de basculer les alias associés vers les nouveaux index à l'issue de la réindexation.

Réindexation complète
=====================

.. caution:: Il est important d'arrêter les services externes ainsi que les tâches planifiées (``scheduler``) et de s'assurer qu'aucun workflow n'est en cours avant de démarrer cette procédure.

La réindexation complète de toutes les collections se déclenche de la manière suivante :

.. code-block:: bash

   ansible-playbook ansible-vitam-exploitation/reindex_es_data.yml -i environments/hosts.<environnement> --ask-vault-pass

Pour les collections par tenant (``unit``, ``objectgroup`` et ``logbookoperation``), il est possible de restreindre la liste des tenants à réindexer en surchargeant la variable ``-e vitam_tenant_ids=<tenantsList>`` à l'exécution de la commande ansible :

.. code-block:: bash

   ansible-playbook ansible-vitam-exploitation/reindex_es_data.yml -i environments/hosts.<environnement> --ask-vault-pass -e "vitam_tenant_ids=[0,1,2]"

La réindexation peut être restreinte à une ou plusieurs collections en spécifiant l'option ``--tags <collection>`` (séparées par des virgules) à l'exécution de la commande ansible.

Voici la liste des collections disponibles pour la réindexation :

* unit
* objectgroup
* logbookoperation
* securityprofile
* context
* ontology
* ingestcontract
* agencies
* accessionregisterdetail
* archiveunitprofile
* accessionregistersummary
* accessionregistersymbolic
* accesscontract
* managementcontract
* fileformat
* filerules
* profile
* griffin
* preservationscenario
* schema

.. caution:: La purge des anciens index n'est pas réalisée par cette procédure scriptée et est laissée à la charge de l'exploitant.

.. caution:: Le rôle elasticsearch-mapping n'est pas joué par ce playbook.
   En cas de modification des fichiers de mapping ES des collections ``unit`` et ``objectgroup``, il faudra rejouer les playbooks ``ansible-vitam/services/vitam/metadata.yml`` et ``ansible-vitam/services/vitam/metadata_collect.yml`` avant de réindexer.

.. caution:: Si un tenant fait partie d'un groupe de tenant, il faudra re-indexer l'ensemble des tenants.

Réindexation différentielle
===========================

.. note:: Applicable uniquement pour les collections ``unit`` et ``objectgroup``.

La réindexation différentielle permet de jouer la réindexation à partir d'une date de départ. Elle est surtout utile dans le cas de collections très volumineuses et que la durée d'interruption de service doit être minimisée.

.. caution:: Attention, si vous conservez le service ouvert durant la réindexation complète des collections ``unit`` et ``objectgroup``, vous devez impérativement interdire les éliminations et les acquittements de transfert tant que la procédure de réindexation différentielle n'est pas terminée.

Ainsi, vous pouvez lancer une réindexation complète sans re-aliasing en ajoutant le paramètre ``-e skip_alias=true``:

.. code-block:: bash

   ansible-playbook ansible-vitam-exploitation/reindex_es_data.yml -i environments/hosts.<environnement> --ask-vault-pass -e "skip_alias=true" --tags unit,objectgroup

.. note:: L'exécution de la réindexation avec ``skip_alias=true`` s'effectue en mode asynchrone et ne retourne donc pas le résultat de fin de réindexation. Il faudra vous assurer du bon déroulement de celle-ci et déterminer la fin de l'opération en consultant les logs du composant metadata.

Vous pouvez consulter la fin de la réindexation au niveau des logs du composant metadata en recherchant le message suivant: ``Reindexation of index {index_name} ended successfully``.

Une fois la réindexation complète terminée, vous devrez récupérer le nom des nouveaux index créés afin de les fournir en paramètre au playbook de réindexation différentielle.

Le playbook de réindexation différentielle prend en paramètre le nom de l'index et calculera automatiquement la date de début (-1 jour) à partir de celle-ci. La date de début peut être surchargée avec le paramètre ``-e indexationStartDate=YYYY-MM-DD``.

Il se chargera aussi de faire la bascule de l'alias associé vers l'index fourni en paramètre.

.. caution:: Il est important d'arrêter les services externes ainsi que les tâches planifiées (``scheduler``) et de s'assurer qu'aucun workflow n'est en cours avant de démarrer la réindexation différentielle.

.. code-block:: bash

   ansible-playbook ansible-vitam-exploitation/reindex_delta_es_data.yml -i environments/hosts.<environnement> --ask-vault-pass -e "index_name=unit_0_20260520_160530"

Cette opération devra être répétée pour l'ensemble des index à re-indexer.
