BeDesk-Express

Il apparaît que le contrôle de l’OCC n’a besoin de se faire qu’au niveau du leader.

En effet, combiné avec le CAS et le hashage de l’arbre de Merkkle du contenu intégral, l’OCC est forcément à jour au moment du contrôle par le leader.

Dans l’éventualité où le contenu serait incomplet ou altéré, le chaînage de hash est le garant qui empêche l’ajout de données incohérente. Forcément, cela se répercute sur l’OCC.

La combinaison du CAS avec le chaînage de hash implique forcément que toute donnée ajoutée au Track doit être la dernière et basée sur un ensemble cohérent et intègre.

Si un follower constate que l’OCC ne correspond pas, il y a 2 options :

1. Ignorer le conflit d’OCC et ajouter la données quant même.
2. S’arrêter immédiatement car rien ne garanti que l’intégrité des données locale est correcte.

Dans le cas n°2, il faut voir à quel moment l’anomalie s’est produite. Elle s’est peut-être produite loin en amont.

De toutes façon, avant de réaliser une sauvegarde de sécurité, il faut ajouter un enregistrement “ping” sur le cluster. De cette manière on s’assure que le nœud contient les dernières données intégrales. On peut donc les sauvegarder. S’il y a un souci, une erreur de checksums sera déclenchée et l’application pourra décider de ne pas procéder à la sauvegarde de sécurité.

Dans le cas n°1, on ne signale pas l’erreur immédiatement. Par contre, au moment d’ajouter un nouvel enregistrement ou d’effectuer la sauvegarde de sécurité, il y aura une erreur SUM_ERROR.

L’anomalie est donc traité d’une manière ou d’une autre.

La stratégie plus laxiste semble à priori suffisante.