J'utilise souvent un système de tables à deux niveaux :
- Table "courante" dans laquelle les événements sont enregistrés
- Table "historique" dans laquelle sont reportés les événements traités.
Ce système permet de conserver un historique tout en ayant des tables "vivantes" peu volumineuses, donc rapides à traiter.
Ce système implique une conservation de la valeur de l'autoincrément pour la table "courante" afin de ne pas avoir de doublons dans la table "historique". C'est encore plus important si la table d'événements est découpée en plusieurs tables physiques qui doivent conserver un identifiant commun.
Ce phénomène était le suivant :
Lorsque la table est vidée et qu'il ne reste plus aucun rang et que vous redémarrez Mysql/MariaDB alors l'incrément repart à 1 et fiche la panique dans ce beau système !
Ce phénomène est heureusement réglé dans MariaDB à partir de la version 10.3.x.
La seule solution que j'ai trouvée est d'utiliser la possibilité d'exécuter une procédure lors du démarrage de Mysql/MariaDB. J'ai donc réalisé :
- Une procédure SQL cataloguée téléchargeable ici.
Cette procédure concerne une "paire" de tables : "RUN_MODSEC" pour la table événements et "HIS_MODSEC" pour la partie historique. -
Un petit fichier SQL (ini_file) de lancement lancé par Mysql/MariaDB lors de son démarrage, ce fichier ne comporte que deux lignes :
use ma_base;
call REINCRT(); - Mes systèmes utilisent "systemd" j'ai donc du modifier le script "mysql.service" de la façon suivante :
| Avant : ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid |
|
Après : ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid --init-file=/etc/mysql/ini_file |
C'est tout !
Cette procédure cataloguée vérifie que l'incrément de la table "vive" n'est pas à 1 et le force à la valeur de l'incrément de la table historique + 1.
J'attends quand même avec impatience de pouvoir passer cette base sous MariaDB 10.3 qui résout, enfin, ce vieux bug. Cela devrait être effectif lors du passage de Stretch à Buster.