MySQL startet nach dem Debian-12-Upgrade nicht mehr: Ursache und Lösung

Das Symptom: MySQL startet nicht mehr (mysql.service failed)

MySQL startet nicht mehr: Der Dienst ist fehlgeschlagen, und das Log meldet den Fehler Can't read dir of '/etc/mysql/mariadb.conf.d/'.

# 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.

Beim Prüfen der installierten Pakete ist MySQL ganz normal vorhanden (mysql-community-server-8.0-Pakete aus dem offiziellen Oracle-Repository).

dpkg -l | grep mysql

Die Ursache: Die Alternative my.cnf zeigt auf mariadb.cnf

Unter Debian ist die Datei /etc/mysql/my.cnf keine echte Datei, sondern ein Link, der von update-alternatives verwaltet wird. Mehrere Pakete können ihre eigene Version registrieren, und im automatischen Modus gewinnt die mit der höchsten Priorität.

Beim Upgrade wurde das Paket mariadb-common installiert (und danach entfernt), das /etc/mysql/mariadb.cnf mit Priorität 500 registriert, höher als /etc/mysql/mysql.cnf (Priorität 300). Das Paket wurde entfernt, aber nicht vollständig gelöscht (Status rc), sodass seine Konfiguration aktiv blieb. In Zeile 29 dieser Datei steht das Include von /etc/mysql/mariadb.conf.d/, einem Verzeichnis, das nicht existiert: MySQL liest die Konfiguration, findet das Verzeichnis nicht und bricht ab. Das Ergebnis: „MySQL startet nicht mehr“, obwohl die Pakete in Ordnung sind.

Die gute Nachricht: Die Daten in /var/lib/mysql wurden nicht angetastet. Es ist nur ein Konfigurationsproblem.

Diagnose: prüfen, worauf my.cnf zeigt

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

Wenn das Problem hier liegt, sieht die Ausgabe ähnlich aus wie diese.

/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

Lösung Schritt für Schritt

1. Die Konfiguration sichern

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

2. Die Reste von mariadb-common entfernen

Das Purge entfernt mariadb.cnf und den zugehörigen Eintrag in update-alternatives.

apt purge mariadb-common

3. my.cnf wieder auf mysql.cnf zeigen lassen

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

4. Die Konfiguration prüfen

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

Jetzt muss my.cnf auf /etc/mysql/mysql.cnf zeigen und /etc/mysql/conf.d/ sowie /etc/mysql/mysql.conf.d/ einbinden. Gibt my_print_defaults mysqld die Parameter ohne Fehler aus, ist die Konfiguration korrekt.

5. MySQL starten

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

Wenn my.cnf kein symbolischer Link ist

Ist /etc/mysql/my.cnf eine normale Datei oder existiert /etc/mysql/mysql.cnf nicht, können Sie die Konfiguration von Hand neu anlegen.

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

Schnelle vorläufige Lösung für „MySQL startet nicht mehr“

Muss die Datenbank sofort wieder online, genügt es, das fehlende Verzeichnis anzulegen. Das ist aber nur ein Provisorium: MySQL würde weiterhin die für MariaDB gedachte Konfiguration lesen, daher wenden Sie die vollständige Lösung besser so bald wie möglich an.

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

Wie Sie verhindern, dass es wieder passiert

Es lohnt sich herauszufinden, welches Upgrade MariaDB installiert hat, anhand des apt-Verlaufs. Wie wir MySQL 5.7 in Docker betreiben, ohne es dem Internet auszusetzen, steht in diesem Artikel. Was sich in Debian 12 geändert hat, erklären die Release Notes zu Debian 12.

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

Damit mariadb-common künftig nicht erneut installiert wird, kann man es mit einem APT-Pin mit negativer Priorität sperren.

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

Nach jedem größeren Upgrade ist es außerdem gute Praxis, den Status der Alternative mit update-alternatives --display my.cnf zu prüfen.

Häufig gestellte Fragen

MySQL startet nicht mehr: Verliere ich die Daten meiner Datenbanken?

Nein. Das Problem betrifft nur die Konfigurationsdateien in /etc/mysql; die Daten in /var/lib/mysql bleiben unversehrt.

Warum hat Debian mariadb.cnf gewählt?

Weil die Alternative my.cnf im automatischen Modus war und mariadb.cnf Priorität 500 hat, höher als die 300 von mysql.cnf. Mit update-alternatives --set wird die Auswahl manuell und ändert sich nicht mehr von selbst.

Gilt das auch für Ubuntu?

Ja, der Mechanismus von update-alternatives für my.cnf ist unter Ubuntu und den anderen von Debian abgeleiteten Distributionen derselbe.

Fazit

Der Fehler „Can’t read dir of /etc/mysql/mariadb.conf.d/“ nach einem Debian-Upgrade bedeutet keinen Schaden an MySQL, sondern eine MariaDB-Restkonfiguration, die über update-alternatives aktiv geblieben ist. Wenn Sie mariadb-common mit apt purge entfernen und my.cnf wieder auf mysql.cnf setzen, läuft MySQL wieder normal.