- État Fermée
- Pourcentage achevé
- Type Spécification
- Catégorie Application → Serveur
-
Assignée à
DevTeam - Système d'exploitation Tous
- Sévérité Critique
- Priorité Très haute
- Basée sur la version 18.0
- Due pour la version 18.0
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par DevTeam - 2018-01-19
Dernière modification par DevTeam - 2018-01-25
FS#1745 - Mise à jour upstream KeylistDB : Ligne courante de réplication dans un fichier mappé
On a constaté que certains problèmes d’OCCL ne proviennent pas d’un conflit de version au moment d’ajouter un nouvel enregistrement. Le leader devrait disposer de toutes les données pour pouvoir enregistrer une nouvelle données supplémentaire. Il a donc forcément contrôlé l’OCCL avant d’enregistrer dans le flux de réplication.
Cependant, on constate que certains utilisateurs rencontre un souci d’OCCL alors qu’ils sont seuls à travailler sur la base de données.
Après vérification, il s’avère que la base du problème n’est pas un souci d’OCCL, mais d’une erreur de CAS.
Pour une raison inconnue, le numéro de ligne de lecture du Track repart à zéro. Ce qui a pour conséquence de faire repartir la lecture du Track à partir du début avec des données qui sont plus récente et donc qui n’ont pas l’OCCL attendu. D’où l’erreur d’OCCL.
Le système fonctionne quant même en protégeant les données locale. Les fichiers locaux restent inchangés.
Cependant, l’erreur annoncée n’est pas correcte.
De plus, on ne sait pas pourquoi le numéro de suivi de la ligne de Track repart à zéro intempestivement.
Il y a peut-être un souci sur le disque de l’utilisateur.
Le problème résulte peut-être du nombre de compaction très fréquent le LogView _Meta qui n’à que très peu d’enregistrements.
—
On peut sans doute remplacer l’enregistrement “replication-agent:follower” de _Meta par un simple fichier mappé qui supportera nettement mieux les ré-écritures.
—
Implémenté sous la forme d’un VMemEngine sur la page “zero” du réplicateur. Nécessite beaucoup moins d’accès disque et est sécurisé par un journal.