Serveur dédié : installation de MariaDB 10.3 photo

MariaDB : réparer les tables système après une mise à jour

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.

Lire la suite

MySQL: résoudre l'erreur "Incorrect datetime value" lors d'opérations sur les tables photo

MySQL/MariaDB : vérifier et réparer les tables après un crash

Il arrive parfois qu’une table SQL soit endommagée après un crash serveur, une coupure brutale, un disque plein, une migration ratée ou un arrêt non propre de MySQL/MariaDB.

Sur un site WordPress, cela peut se traduire par une erreur de connexion à la base, des requêtes qui échouent, des tables marquées comme “crashed”, ou des messages dans les logs MySQL/MariaDB.

À l’époque, j’avais écrit un petit script Bash qui stoppait MySQL, lançait myisamchk sur toutes les tables .MYI, puis relançait MySQL, Apache et Varnish.

Cette méthode pouvait dépanner sur de vieilles bases en MyISAM. Aujourd’hui, elle doit être utilisée avec beaucoup plus de prudence, car la plupart des tables modernes sont en InnoDB. Et InnoDB ne se répare pas avec myisamchk.

Lire la suite

terminal-icon

Linux : ajouter un utilisateur à un groupe sans supprimer ses droits

Il m’est arrivé une mésaventure avec la commande usermod sous Linux. Dans un terminal, usermod sert à modifier un compte utilisateur : groupes, shell, répertoire personnel, nom de login, date d’expiration, etc.

Le cas le plus courant consiste à ajouter un utilisateur à un groupe, par exemple pour lui donner accès à Docker, à des fichiers partagés, à un groupe système, ou à certaines permissions.

Le problème, c’est que beaucoup d’exemples anciens donnent cette commande :

sudo usermod -G groupname username

Elle semble correcte. Elle ne l’est pas, sauf si vous voulez remplacer entièrement la liste des groupes secondaires de l’utilisateur.

La bonne commande pour ajouter un utilisateur à un groupe sans lui retirer ses groupes actuels est :

sudo usermod -aG groupname username

Le petit -a change tout. Sans lui, -G définit la nouvelle liste de groupes supplémentaires. Avec lui, -G ajoute le groupe à la liste existante.

Le piège de usermod -G

Imaginons un utilisateur matt qui appartient déjà à plusieurs groupes :

groups matt

Résultat :

matt : matt sudo adm cdrom dip plugdev lpadmin

Si vous lancez :

sudo usermod -G docker matt

vous ne faites pas seulement “ajouter matt au groupe docker”. Vous remplacez ses groupes secondaires par docker.

Après reconnexion, l’utilisateur peut donc perdre des groupes importants comme sudo, adm, lpadmin ou plugdev. Et là, c’est tout de suite moins drôle. Surtout si vous venez de vous retirer vos propres droits sudo. Grand classique, petit frisson.

Lire la suite