Le contexte : un client ScalarX a effectué une mise à jour d’une ancienne version de MySQL vers une version un peu moins ancienne de MariaDB (10.5) sur un serveur (dans la pratique une machine virtuelle CentOS sous Proxmox VE).

Cette mise à jour a été effectuée pour des raisons de compatibilité applicative : avec un peu plus de 350 applications hébergées, MariaDB 10.5 offrait un compromis idéal en étant compatible avec les versions les plus anciennes comme les plus récentes des applications et sites de ses clients.

Le client effectue le monitoring applicatif de chaque site internet / application qu’il héberge et tout fonctionnait bien. Aujourd’hui, ce 25 décembre 2024, le monitoring ScalarX remonte une utilisation excessive de la partition système entrainant une intervention analytique et corrective.

La source de l’alerte provient d’un fichier d’erreur MariaDB qui s’est progressivement rempli jusqu’à atteindre le seuil d’alerte. On pouvait y lire des erreurs du type :

2024-12-25 17:39:20 46728158 [ERROR] InnoDB: Column last_update in table `mysql`.`innodb_table_stats` is BINARY(4) NOT NULL but should be INT UNSIGNED NOT NULL (flags mismatch).
2024-12-25 17:39:20 46728158 [ERROR] InnoDB: Fetch of persistent statistics requested for table `xxxxxxx`.`LUKwsQnl_actionscheduler_actions` but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

Ce type d’incident se produit parfois lorsque mysql_upgrade ne s’est pas correctement exécuté lors de la mise à jour. On tente donc dans un premier temps de forcer l’upgrade, mais toutes les tables sont OK, aucune correction n’est effectuée.

Après avoir effectué deux snapshots de la VM, on procède alors à la suppression des tables problématiques :

DROP TABLE IF EXISTS mysql.innodb_table_stats;
DROP TABLE IF EXISTS mysql.innodb_index_stats;

Cette opération est suivie d’une relance du serveur MariaDB et enfin de l’exécution à nouveau d’un mysql_upgrade –force afin de s’assurer que les tables soient recréées proprement.

Une fois ces opérations effectuées, plus aucune erreur n’est remontée.

Alors que l’on procède à une vérification côté serveur MariaDB / MySQL, le client vérifie de son côté le bon fonctionnement des sites et applications via son monitoring applicatif :

SHOW TABLES LIKE 'innodb_%';
DESCRIBE innodb_table_stats;
DESCRIBE innodb_index_stats;
SELECT COUNT(*) FROM innodb_table_stats;
SELECT COUNT(*) FROM innodb_index_stats;

Tout est ok pour ce jour de Noël comme un autre ;). Pensez à sauvegarder *avant* de tenter ce type d’opérations.
 
 
—
Christophe Casalegno
Vous pouvez me suivre sur : Telegram | Facebook | LinkedIn | Twitter | YouTube | Twitch