MySQL no arranca tras actualizar a Debian 12: causa y solución

El síntoma: MySQL no arranca y mysql.service queda en failed

Tras actualizar a Debian 12, MySQL no arranca. El servicio figura como fallido y el log muestra el error 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.

Al comprobar los paquetes instalados, MySQL está presente con normalidad (paquetes mysql-community-server 8.0 del repositorio oficial de Oracle).

dpkg -l | grep mysql

La causa: la alternativa my.cnf apunta a mariadb.cnf

En Debian el archivo /etc/mysql/my.cnf no es un archivo real. Es un enlace gestionado por update-alternatives. Varios paquetes pueden registrar su propia versión y, en modo automático, gana la que tiene la prioridad más alta.

Durante la actualización se instaló (y luego se eliminó) el paquete mariadb-common. Registra /etc/mysql/mariadb.cnf con prioridad 500, más alta que /etc/mysql/mysql.cnf (prioridad 300). El paquete se eliminó pero no se purgó del todo (estado rc), así que su configuración siguió activa. En la línea 29 de ese archivo hay la inclusión de /etc/mysql/mariadb.conf.d/, un directorio que no existe. MySQL lee la configuración, no encuentra el directorio y se detiene.

Buena noticia: los datos en /var/lib/mysql no se han tocado. Es solo un problema de configuración.

Diagnóstico: comprobar adónde apunta 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 el problema es este, la salida será parecida a la siguiente.

/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

Solución paso a paso

1. Hacer una copia de seguridad de la configuración

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

2. Eliminar los restos de mariadb-common

El purge elimina mariadb.cnf y su entrada en update-alternatives.

apt purge mariadb-common

3. Volver a apuntar my.cnf a mysql.cnf

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

4. Comprobar la configuración

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

Ahora my.cnf debe apuntar a /etc/mysql/mysql.cnf e incluir /etc/mysql/conf.d/ y /etc/mysql/mysql.conf.d/. Si my_print_defaults mysqld muestra los parámetros sin errores, la configuración es correcta.

5. Arrancar MySQL

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

Si my.cnf no es un enlace simbólico

Si /etc/mysql/my.cnf es un archivo normal o /etc/mysql/mysql.cnf no existe, se puede recrear la configuración a mano.

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

Solución rápida provisional

Si MySQL no arranca y hace falta volver a poner la base de datos en línea enseguida, basta con crear la carpeta que falta. Pero es solo un parche: MySQL seguiría leyendo la configuración pensada para MariaDB. Conviene aplicar la solución completa cuanto antes.

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

Cómo evitar que vuelva a ocurrir

Conviene averiguar qué actualización instaló MariaDB, consultando el historial de apt.

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

Para impedir que mariadb-common se reinstale en el futuro se puede bloquear con un pin de APT de prioridad negativa.

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

Después de cada actualización importante es buena costumbre comprobar también el estado de la alternativa con update-alternatives --display my.cnf. Las notas de la versión de Debian 12 recogen los cambios de la actualización.

Si necesitas una versión antigua de MySQL en el mismo servidor, mira cómo aislar MySQL 5.7 en Docker con nftables.

Preguntas frecuentes

¿Pierdo los datos si MySQL no arranca?

No. El problema afecta solo a los archivos de configuración en /etc/mysql; los datos en /var/lib/mysql permanecen intactos.

¿Por qué eligió Debian mariadb.cnf?

Porque la alternativa my.cnf estaba en modo automático y mariadb.cnf tiene prioridad 500, más alta que los 300 de mysql.cnf. Con update-alternatives --set la elección pasa a ser manual y ya no cambia sola.

¿Vale también para Ubuntu?

Sí, el mecanismo de update-alternatives para my.cnf es el mismo en Ubuntu y en las demás distribuciones derivadas de Debian.

Conclusión

El error «Can’t read dir of /etc/mysql/mariadb.conf.d/» tras una actualización de Debian no indica un daño en MySQL. Es una configuración residual de MariaDB que ha quedado activa mediante update-alternatives. Al eliminar mariadb-common con apt purge y volver a poner my.cnf en mysql.cnf, MySQL vuelve a funcionar con normalidad.