MySQL ne démarre plus après la mise à jour vers Debian 12 : cause et solution

Le symptôme : mysql.service à l’état failed

Sous Debian 12, MySQL ne démarre plus. Le service apparaît en échec et le log signale l’erreur Can't read dir of '/etc/mysql/mariadb.conf.d/'.

Voici la sortie complète :

# service mysql status
× mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: failed (Result: exit-code)
     Status: "Server startup in progress"

mysqld: Can't read dir of '/etc/mysql/mariadb.conf.d/' (OS errno 2 - No such file or directory)
mysqld: [ERROR] Stopped processing the 'includedir' directive in file /etc/mysql/my.cnf at line 29.
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
systemd[1]: Failed to start mysql.service - MySQL Community Server.

En vérifiant les paquets installés, MySQL est bien présent (paquets mysql-community-server 8.0 du dépôt officiel Oracle) :

dpkg -l | grep mysql

La cause : l’alternative my.cnf pointe vers mariadb.cnf

Sous Debian, le fichier /etc/mysql/my.cnf n’est pas un vrai fichier. C’est un lien géré par update-alternatives. Plusieurs paquets peuvent enregistrer leur propre version. En mode automatique, celle qui a la priorité la plus haute l’emporte.

Pendant la mise à jour, le paquet mariadb-common a été installé (puis retiré). Il enregistre /etc/mysql/mariadb.cnf avec une priorité de 500, supérieure à celle de /etc/mysql/mysql.cnf (priorité 300). Le paquet a été retiré mais pas entièrement purgé (état rc). Sa configuration est donc restée active. À la ligne 29 de ce fichier se trouve l’inclusion de /etc/mysql/mariadb.conf.d/, un répertoire qui n’existe pas. MySQL lit la configuration, ne trouve pas le répertoire et s’arrête.

Bonne nouvelle : les données dans /var/lib/mysql n’ont pas été touchées. Ce n’est qu’un problème de configuration.

Diagnostic : vérifier vers où pointe my.cnf

ls -l /etc/mysql/my.cnf /etc/alternatives/my.cnf
update-alternatives --display my.cnf
sed -n '25,32p' /etc/mysql/my.cnf
dpkg -l | grep -i mariadb

Si le problème est bien celui-ci, la sortie ressemblera à ceci :

/etc/alternatives/my.cnf -> /etc/mysql/mariadb.cnf
/etc/mysql/my.cnf -> /etc/alternatives/my.cnf

my.cnf - modalità automatica
  la versione migliore del collegamento è /etc/mysql/mariadb.cnf
  il collegamento attualmente punta a /etc/mysql/mariadb.cnf
/etc/mysql/mariadb.cnf - priorità 500
/etc/mysql/my.cnf.fallback - priorità 100
/etc/mysql/mysql.cnf - priorità 300

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

rc  mariadb-common   1:10.11.18-0+deb12u1   all   MariaDB common configuration files

Solution pas à pas

1. Sauvegarder la configuration

cp -a /etc/mysql /root/etc-mysql-backup-$(date +%F)

2. Supprimer les résidus de mariadb-common

La purge supprime mariadb.cnf et son entrée dans update-alternatives :

apt purge mariadb-common

3. Repointer my.cnf vers mysql.cnf

update-alternatives --remove my.cnf /etc/mysql/mariadb.cnf 2>/dev/null
update-alternatives --set my.cnf /etc/mysql/mysql.cnf

4. Vérifier la configuration

update-alternatives --display my.cnf
cat /etc/mysql/my.cnf
my_print_defaults mysqld

Désormais my.cnf doit pointer vers /etc/mysql/mysql.cnf et inclure /etc/mysql/conf.d/ et /etc/mysql/mysql.conf.d/. Si my_print_defaults mysqld affiche les paramètres sans erreur, la configuration est correcte.

5. Démarrer MySQL

systemctl start mysql
systemctl status mysql
journalctl -u mysql -n 50 --no-pager

Si my.cnf n’est pas un lien symbolique

Si /etc/mysql/my.cnf est un fichier normal ou si /etc/mysql/mysql.cnf n’existe pas, on peut recréer la configuration à la main :

mv /etc/mysql/my.cnf /etc/mysql/my.cnf.mariadb.bak
cat > /etc/mysql/my.cnf <<'EOF'
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
EOF
mkdir -p /etc/mysql/conf.d
systemctl start mysql

Solution rapide quand MySQL ne démarre plus

S’il faut remettre la base en ligne tout de suite, créez le dossier manquant. Ce n’est toutefois qu’un pis-aller. MySQL continuerait à lire la configuration prévue pour MariaDB. Il vaut donc mieux appliquer la solution complète dès que possible.

mkdir /etc/mysql/mariadb.conf.d && systemctl start mysql

Comment éviter que cela se reproduise

Il est utile de comprendre quelle mise à jour a installé MariaDB, en consultant l’historique d’apt :

grep -i -B3 -A3 mariadb /var/log/apt/history.log*

Pour empêcher mariadb-common d’être réinstallé à l’avenir, on peut le bloquer avec un pin APT à priorité négative :

cat > /etc/apt/preferences.d/no-mariadb <<'EOF'
Package: mariadb-*
Pin: release *
Pin-Priority: -1
EOF

Après chaque mise à jour importante, c’est aussi une bonne habitude de vérifier l’état de l’alternative avec update-alternatives --display my.cnf.

Les notes de version de Debian 12 décrivent les changements de cette version.

Un autre piège de configuration à connaître : MySQL 5.7 dans Docker et le port 3306 exposé.

Questions fréquentes

Vais-je perdre les données de mes bases ?

Non. Le problème ne concerne que les fichiers de configuration dans /etc/mysql ; les données dans /var/lib/mysql restent intactes.

Pourquoi Debian a-t-il choisi mariadb.cnf ?

Parce que l’alternative my.cnf était en mode automatique et que mariadb.cnf a une priorité de 500, supérieure aux 300 de mysql.cnf. Avec update-alternatives --set, le choix devient manuel et ne change plus tout seul.

Cela vaut-il aussi pour Ubuntu ?

Oui, le mécanisme de update-alternatives pour my.cnf est le même sur Ubuntu et sur les autres distributions dérivées de Debian.

Conclusion

L’erreur « Can’t read dir of /etc/mysql/mariadb.conf.d/ » n’indique pas que MySQL est endommagé. Quand MySQL ne démarre plus, le coupable est une configuration résiduelle de MariaDB. Elle est restée active via update-alternatives. En supprimant mariadb-common avec apt purge et en remettant my.cnf sur mysql.cnf, MySQL refonctionne normalement.