Sur l’un des serveurs de mes clients Codeable, j’ai mis à jour MariaDB de la version 10.1 à la version 10.3. Après la mise à jour, MariaDB fonctionnait encore et le site s’affichait correctement, mais certaines procédures SQL retournaient cette erreur :
ERROR 1558 (HY000): Column count of mysql.proc is wrong. Expected 21, found 20.
Created with MariaDB 100212, now running 100303.
Please use mysql_upgrade to fix this errorCode language: JavaScript (javascript)
Cette erreur peut apparaître après une mise à jour majeure de MariaDB lorsque les tables système internes n’ont pas encore été mises à niveau.
En clair : le serveur MariaDB a été mis à jour, mais la base système mysql contient encore des tables dans l’ancien format.
Comprendre l’erreur “Column count of mysql.proc is wrong”
Le message indique que la table système mysql.proc n’a pas la structure attendue par la version actuelle de MariaDB.
Dans l’exemple :
Expected 21, found 20
MariaDB attend une table avec 21 colonnes, mais la table existante n’en possède que 20. Elle a été créée avec une ancienne version, puis le serveur a été lancé avec une version plus récente.
MariaDB documente l’erreur 1558 comme un signe probable qu’une mise à jour n’a pas été effectuée correctement, car l’une des tables système ne correspond pas à la taille attendue par la version en cours. La documentation indique que mariadb-upgrade règle généralement ce problème. MariaDB : Error 1558
Cette erreur apparaît souvent lors de l’utilisation de :
- procédures stockées ;
- fonctions stockées ;
- triggers ;
- events ;
- outils d’export ;
- interfaces d’administration comme phpMyAdmin, Plesk ou scripts maison.
Le site peut donc continuer à fonctionner en apparence, tout en ayant une base système incomplètement migrée. C’est le genre d’erreur discrète qui attend poliment le bon moment pour casser un export. Très courtois, très SQL.
La solution moderne : lancer mariadb-upgrade
Sur une installation MariaDB moderne, utilisez :
sudo mariadb-upgrade
Ou, si votre utilisateur root MariaDB nécessite un mot de passe :
mariadb-upgrade -u root -p
Sur les anciennes installations, la commande était :
mysql_upgrade -u root -p
MariaDB indique que depuis MariaDB 10.5, le client s’appelle mariadb-upgrade, tout en restant parfois accessible via l’ancien nom mysql_upgrade sous forme de symlink ou de binaire alternatif selon les plateformes. MariaDB : mysql_upgrade
La documentation de mariadb-upgrade précise qu’il faut l’exécuter après une mise à jour majeure de MySQL/MariaDB vers une autre version majeure, et qu’il est aussi sûr de l’exécuter après une mise à jour mineure : s’il n’y a rien à modifier, rien n’est changé. MariaDB : mariadb-upgrade
Redémarrer MariaDB après l’upgrade
Après l’exécution de mariadb-upgrade, redémarrez MariaDB :
Votre base de données ralentit tout ?
Tables wp_options surchargées, autoload incontrôlé, requêtes non indexées — une base WordPress mal entretenue finit toujours par plomber les temps de réponse. Je l'audite, je la nettoie, je l'optimise.
Diagnostiquons votre base de données →sudo systemctl restart mariadb
Sur une ancienne installation MySQL/MariaDB dont le service s’appelle encore mysql :
sudo systemctl restart mysql
Ou, sur un très vieux système :
sudo service mysql restart
Ensuite, vérifiez le statut :
systemctl status mariadb --no-pager
systemctl status mysql --no-pager
Et relisez les derniers logs :
journalctl -u mariadb -n 100 --no-pager
journalctl -u mysql -n 100 --no-pager
Vérifier les versions avant et après
Avant de corriger, il est utile de noter la version du client et du serveur :
mariadb --version
mariadbd --version
Ou avec les anciens binaires :
mysql --version
mysqld --version
Depuis SQL :
sudo mariadb -e "SELECT VERSION();"Code language: JavaScript (javascript)
Ou :
mysql -u root -p -e "SELECT VERSION();"Code language: JavaScript (javascript)
Ces informations permettent de confirmer que le serveur tourne bien avec la version attendue, et non avec un mélange de paquets client/serveur incohérents.
Vérifier si mariadb-upgrade est disponible
Selon la distribution, les deux commandes peuvent coexister :
command -v mariadb-upgrade
command -v mysql_upgrade
Vous pouvez aussi regarder les fichiers :
ls -l /usr/bin/mariadb-upgrade /usr/bin/mysql_upgrade 2>/dev/nullCode language: JavaScript (javascript)
Sur MariaDB 10.5+, commencez par mariadb-upgrade. Si seul mysql_upgrade est disponible, utilisez-le.
Sauvegarder avant une mise à niveau majeure
Avant de lancer une mise à niveau majeure MariaDB, faites toujours une sauvegarde complète.
sudo mariadb-dump --all-databases --single-transaction --routines --triggers --events \
| gzip > all-databases-before-upgrade-$(date +%Y%m%d-%H%M%S).sql.gzCode language: JavaScript (javascript)
Avec les anciens outils :
sudo mysqldump --all-databases --single-transaction --routines --triggers --events \
| gzip > all-databases-before-upgrade-$(date +%Y%m%d-%H%M%S).sql.gzCode language: JavaScript (javascript)
L’option --routines est particulièrement importante ici, puisque l’erreur concerne souvent les procédures et fonctions stockées.
Un dump non testé reste une promesse. Si la base est critique, testez la restauration sur une machine de staging avant de toucher la production.
Pourquoi apt n’a-t-il pas tout fait ?
Selon les versions, distributions et paquets, l’installation via apt met à jour les binaires MariaDB, mais les tables système peuvent nécessiter une étape supplémentaire.
Historiquement, cette étape se faisait avec :
mysql_upgrade
Aujourd’hui, côté MariaDB, on utilise plutôt :
mariadb-upgrade
Cette commande vérifie les tables, met à jour les tables système et adapte les privilèges ou structures internes nécessaires à la version en cours. La page de manuel Debian de mysql_upgrade explique que l’outil examine toutes les tables pour détecter les incompatibilités et met aussi à jour les tables système pour permettre les nouveaux privilèges ou fonctionnalités. Debian manpage : mysql_upgrade
Tester les procédures après correction
Après mariadb-upgrade et redémarrage, testez les procédures ou fonctions qui échouaient.
Listez les procédures :
SHOW PROCEDURE STATUS;
Listez les fonctions :
SHOW FUNCTION STATUS;Code language: PHP (php)
Ou depuis le terminal :
sudo mariadb -e "SHOW PROCEDURE STATUS\G" | head -n 80Code language: JavaScript (javascript)
Si l’erreur 1558 ne réapparaît plus, les tables système sont à nouveau cohérentes avec la version du serveur.
Vérifier toutes les tables après upgrade
Après une montée de version, vous pouvez aussi vérifier les tables avec :
sudo mariadb-check --all-databases --check
Ou, sur ancienne installation :
sudo mysqlcheck --all-databases --check
Ce n’est pas toujours obligatoire, mais cela donne une vérification supplémentaire après une migration importante.
Cas Docker ou conteneur MariaDB
Dans un conteneur, il arrive que mysql_upgrade ou mariadb-upgrade ne soit pas disponible dans l’image, ou que le conteneur lance automatiquement certaines étapes.
Commencez par entrer dans le conteneur :
docker exec -it mariadb bash
Puis vérifiez :
command -v mariadb-upgrade
command -v mysql_upgrade
mariadb --version
Si l’outil existe :
mariadb-upgrade -u root -p
Sinon, vérifiez la documentation de l’image utilisée. Certaines images MariaDB modernes gèrent l’upgrade différemment au démarrage, mais vous devez tout de même confirmer que les tables système ont bien été mises à niveau.
Cas Plesk, cPanel et panels d’administration
Sur un serveur avec Plesk, cPanel ou autre panel, ne lancez pas une mise à niveau majeure de MariaDB au hasard. Ces panels ont souvent leur propre procédure de mise à jour, leurs dépendances et leurs scripts internes.
L’erreur Column count of mysql.proc is wrong peut notamment apparaître lors d’un export ou d’une opération depuis un panel si la base système n’a pas été mise à jour. Mais la correction doit respecter l’écosystème du panel.
Dans ce cas, vérifiez d’abord la documentation du panel, puis exécutez la commande d’upgrade recommandée dans le bon contexte utilisateur.
Ne pas modifier mysql.proc à la main
Ne tentez pas de corriger l’erreur en ajoutant une colonne à mysql.proc à la main.
Même si l’erreur dit “Expected 21, found 20”, la solution n’est pas de bricoler la table système avec un ALTER TABLE trouvé au détour d’un forum.
La bonne méthode est d’utiliser l’outil d’upgrade fourni par MariaDB, car il applique l’ensemble des changements attendus pour la version courante.
Les tables système, c’est comme le tableau électrique : oui, on peut mettre les doigts dedans, mais il vaut mieux savoir très exactement pourquoi.
Procédure complète recommandée
Voici la séquence que j’utiliserais aujourd’hui après une montée de version MariaDB :
- Faire une sauvegarde complète avec routines, triggers et events.
- Vérifier la version MariaDB installée.
- Vérifier que le service démarre correctement.
- Lancer
mariadb-upgradeoumysql_upgradeselon la version. - Redémarrer MariaDB.
- Vérifier les logs.
- Tester les procédures/fonctions qui échouaient.
- Vérifier les tables avec
mariadb-checksi nécessaire.
Commandes rapides
# Vérifier les versions.
mariadb --version
mariadbd --version
sudo mariadb -e "SELECT VERSION();"
# Sauvegarder avant upgrade.
sudo mariadb-dump --all-databases --single-transaction --routines --triggers --events \
| gzip > all-databases-before-upgrade-$(date +%Y%m%d-%H%M%S).sql.gz
# Trouver la commande d’upgrade.
command -v mariadb-upgrade
command -v mysql_upgrade
# Upgrade moderne MariaDB.
sudo mariadb-upgrade
# Avec mot de passe.
mariadb-upgrade -u root -p
# Ancienne commande.
mysql_upgrade -u root -p
# Redémarrer.
sudo systemctl restart mariadb
# ou
sudo systemctl restart mysql
# Vérifier les logs.
journalctl -u mariadb -n 100 --no-pager
journalctl -u mysql -n 100 --no-pager
# Vérifier les tables.
sudo mariadb-check --all-databases --check
sudo mysqlcheck --all-databases --checkCode language: PHP (php)
Mémo rapide
# Erreur.
ERROR 1558 (HY000): Column count of mysql.proc is wrong.
Expected 21, found 20.
Please use mysql_upgrade to fix this error
# Cause.
# Les tables système MariaDB n’ont pas été mises à jour après une montée de version.
# Solution moderne.
sudo mariadb-upgrade
sudo systemctl restart mariadb
# Ancienne solution.
mysql_upgrade -u root -p
sudo systemctl restart mysql
# Vérification.
sudo mariadb -e "SELECT VERSION();"
sudo mariadb -e "SHOW PROCEDURE STATUS;"Code language: PHP (php)
Conclusion
L’erreur Column count of mysql.proc is wrong apparaît généralement après une mise à jour MariaDB incomplète. Le serveur a été mis à jour, mais les tables système de la base mysql sont restées dans l’ancien format.
La solution consiste à lancer l’outil d’upgrade MariaDB :
sudo mariadb-upgrade
ou, sur les anciennes versions :
mysql_upgrade -u root -p
Puis à redémarrer le service :
sudo systemctl restart mariadb
Après cela, les procédures stockées, fonctions, triggers et outils d’export retrouvent normalement un comportement correct.
En résumé : après une montée de version majeure MariaDB, ne vous contentez pas d’installer les paquets. Lancez aussi l’upgrade des tables système. Sinon, MariaDB démarre, sourit, puis vous rappelle au mauvais moment qu’il a encore un pied dans l’ancienne version.
Votre hébergement est devenu un problème ?
Serveur partagé saturé, limites PHP trop basses, support qui répond en 48h — à un certain niveau de trafic, l'hébergement mutualisé devient le goulot. Je migre et configure des serveurs dédiés.
Parlons de votre infrastructure →
