5.2. Audit de cohérence de données entre MongoDb et Elasticsearch¶

Cette partie décrit le process de l’audit de cohérence de données dans Vitam.

5.2.1. Principe de fonctionnement¶

5.2.1.1. Configuration¶

Il s’agit en premier temps de pouvoir se connecter sur les différents shards du mongod ( sachant qu’un seul peut shard contient 1 ou plusieurs noeuds : lieu de stockage de data ) NB: A ce jour, Vitam utilise un seul shard mongod. Cette configuration existe dans le fichier metadata.conf :

mongodShardsConf:
 dbUserName: vitamdb-localadmin
 dbPassword: qwerty
 mongoDbShards:
   - shardName: shard0
     mongoDbNodes:
       - dbHost: 172.17.0.2
         dbPort: 27019

On ajoute à cette configuration d’autres paramètres qui permettent de gérer l’audit :

isDataConsistencyAuditRunnable: Permet de lancer ou pas l’audit
dataConsistencyAuditOplogMaxSize: Spécifier la taille maximale de données à lire depuis les oplog par noeud!

5.2.1.2. Exécution¶

Une fois l’audit est accessible, un contrôle est fait sur l’existence d’un audit qui pourrait déjà être en cours. S’il n’y a pas d’audit en cours, Vitam crée un logbook pour la fonctionnalité, puis les clients de connexions MongoDB. Vitam procède ensuite à la lecture des différents oplog des nœuds.

5.2.1.3. Lecture de l’oplog¶

L’oplogReader permet de parcourir l’ensemble des opérations de l’oplog et d’extraire les opérations les plus récentes de type (insert, update et delete) sur les collections « Unit » et « ObjectGroup » et qui ont une date d’opération postérieure à la dernière date de lancement d’audit ( fichier de configuration nommé « mongoDbShardsTimestampConfiguration.json » placé dans /workspace/dataConsistencyAuditContainer ).

5.2.1.4. Traitement des opérations de l’oplog MongoDB et comparaison avec ES¶

Une fois les opérations d’oplog récupérées et traitées, une comparaison sera faite avec les opérations associées et récupérées depuis d’Elasticsearch afin de vérifier la cohérence et générer les différences.

5.2.1.5. Comportement de l’audit suite à la comparaison de données¶

Une fois la comparaison terminée, on distingue 2 cas de figure :

0 différences : le logbook passera en mode success et on quitte l’audit.
Existence de différences : dans ce cas une correction sur ES devrait être faite, et une nouvelle comparaison faite par rapport à ce correctif. A ce stade, on distingue à nouveau 2 cas de figure :
- 0 différences : ( Données corrigées sur ES ) le logbook passera en mode warning
- Existence de différences : ( Données non corrigées sur ES ) le logbook passera en mode ko

5.2.2. Lancement de l’audit¶

L’audit est un lancé par un timer configuré dans vitam_vars.yml :

metadata:
    - ....
    - ....
    - name: vitam-metadata-audit-mongodb-es
      frequency: "2020-01-01 00:00:00"

Pour pouvoir lancer l’audit, il faut :

Modifier la fréquence de lancement du timer selon le besoin.
Setter isDataConsistencyAuditRunnable à true au niveau de metadata.conf

Il s’agit d’une fonction de recette, a ne pas utiliser en production.