5.25. 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.

5.25.1. Réindexation complète

Prudence

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 :

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 :

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

Prudence

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.

Prudence

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.

Prudence

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

5.25.2. 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.

Prudence

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:

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.

Prudence

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.

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.