Il y a plusieurs mois, le 23 mai 2024, notre site s’est retrouvé hors service à cause d’un disque saturé par 19 Go de logs d’erreurs MySQL. La faute à une rotation des logs absente. À l’époque, j’avais pensé que mettre en place cette rotation suffirait à régler le problème.

Malheureusement, deux mois plus tard, le serveur était à nouveau en panne. Après de longues galères, une correction de la table système column_stats avait permis de tout faire rentrer dans l’ordre... du moins en apparence. En réalité, chaque redémarrage du serveur déclenchait des problèmes avec les tables utilisant le moteur de stockage InnoDB. Pour contourner la difficulté, j’avais basculé toutes les tables sur MyISAM et caché le problème sous le tapis — vacances obligent. Puis s'en est suivit le "gel SI" lié à l’ouverture des inscriptions pour la LAN'Oween.

Les mois passant, et sans souci apparent, j’avais laissé ce problème de côté, par manque de temps et d’envie. Jusqu’à ce qu’un nouveau crash survienne, cette fois-ci pendant des vacances au ski (décidément !).

C’est à ce moment que j’ai enfin décidé de m’y attaquer sérieusement, avec l’aide précieuse de ChatGPT.

La source du problème venait d’un écart de version : le serveur MariaDB était en 10.11.6, mais les tables système étaient restées en 10.3.27. En plus de cela, plusieurs tables système critiques étaient corrompues (innodb_index_stats, innodb_table_stats, transaction_registry, et gtid_slave_pos). Ces tables étaient signalées comme "inexistantes" par le moteur InnoDB, ce qui causait des erreurs lors des commandes comme mysqlcheck et empêchait mysql_upgrade de fonctionner correctement.

Voyant qu’une reconstruction était impossible, j’ai pris les mesures suivantes :

1. Suppression des fichiers .frm et .ibd des tables corrompues.
2. Recréation manuelle de ces tables via des requêtes SQL adaptées.
3. Exécution du mysql_upgrade, cette fois avec succès.

Le problème a finalement été entièrement résolu, et le serveur MariaDB est de nouveau opérationnel.