Le mécanisme de prise en compte de ces traces par tous les nœuds, et leur suppression de la table par le leader, peut être personnalisé à l'aide des propriétés suivantes (listées ici avec leurs valeurs par défaut, issues en général du fichier /WEB-INF/jalios/jcms.prop) :
Pour tous les nœuds
Période - en minutes - entre chaque opération
Tous les noeuds : prise en compte des traces
Leader : à la suite de cela, lancement d'un "scan" du mécanisme de suppression des traces
dbeventlog.scan-freq: 1
Nombre maximum de traces à récupérer de la table, pour des raisons de performance
Tous les nœuds : lors de chaque opération de prise en compte (ne pas tenir compte du ".clean" dans le nom de la propriété - raisons historiques...)
Leader : lors d'un scan du mécanisme de suppression
dbeventlog.clean.query.max-results: 1000
Pour le leader, paramétrage du mécanisme de suppression des traces, lors d'un scan
Une trace est supprimée dès que l'une de ces conditions au moins est vérifiée :
Durée maximum - en minutes - de la présence d'une trace dans la table (1440 = 24 heures par défaut...)
dbeventlog.clean.time-limit: 1440
Nombre de nœuds dans le cluster (leader + réplicas)
Si le nombre de nœuds (au moment du scan) est supérieur ou égal à ce nombre, et s'ils ont tous traité une trace, cette dernière pourra être supprimée avant le "time-limit".
Conseil : le nombre de nœuds en réalité étant bien inférieur à la valeur par défaut, ce paramètre ne sera pas pris en compte. Il est donc conseillé de spécifier le nombre de nœuds effectifs dans l'installation en production (2 bien souvent...), notamment s'il a été constaté que le nombre de lignes dans la table DBEventLog devenait important (plusieurs centaines ou milliers de lignes), causant ainsi des asynchronismes entre les nœuds...
dbeventlog.clean.urid-count: 10
Fonctionnement à partir de la version 9 SP3
A partir de JCMS 9 SP3 le mode de fonctionnement de la synchronisation entre les instances a été modifié.
Afin d'optimiser les performances, d'améliorer la reprise sur erreur et de limiter les engorgements liés à la trop grande volumétrie de la table j_dbeventlog, le leader va créer une entrée dans celle-ci pour chaque replica identifié.
De cette manière, chaque replica ne consulte que les enregistrements qui le concernent directement, et a pour tâche de supprimer ceux-ci une fois qu'il les a traités.
A cet effet, la configuration de jsync évolue. Une nouvelle propriété dbeventlog.explicit-urids a fait son apparition, et va permettre au leader de transférer chaque mise à jour qu'il reçoit à chaque replica indiqué dans celle-ci. Les propriétés décrites précédemment (en dehors de dbeventlog.scan-freq) deviennent obsolètes.
La configuration devient alors :
Pour tous les noeuds :
channel.url: # pas spécifique à jsync mais doit être correctement configurée pour fonctionner
channel.urid: # pas spécifique à jsync mais doit être correctement configurée pour fonctionner
Pour le leader :
jsync.replica-url: # url privée du replica (généralement adresse ip + port d'accès à tomcat + context root)
jsync.leader-url: # laisser vide : il s'agit de la configuration du leader
...
jsync.explicit-replica-list: # renseigner les urls des replicas séparées par un espace
dbeventlog.explicit-urids: # renseigner les urids des replicas, séparés par un espace
Pour chaque replica :
jsync.replica-url: # url privée du replica (généralement adresse ip + port d'accès à tomcat + context root)
jsync.leader-url: # cette valeur doit être renseignée
...
jsync.explicit-replica-list: # laisser vide
dbeventlog.explicit-urids: # laisser vide
Remarques :
Dans la version 9 SP3, vous pouvez avoir besoin du patch JCMS-5558
Vous pouvez activer le nouveau mode de réplication dès la 9 SP2 avec le patch JCMS-5387
