Quand MySQL ou MariaDB ne démarre pas, lisez d’abord systemctl status mysql et le journal d’erreurs. Les causes fréquentes sont un disque plein, une mémoire épuisée tuée par l’OOM killer, une option de configuration invalide ou des tables InnoDB corrompues. Dans ce dernier cas, copiez le dossier de données avant d’essayer innodb_force_recovery.
Une base de données qui s’arrête emporte avec elle tous les sites qui en dépendent : WordPress affiche alors « Error establishing a database connection ». Le service peut refuser de démarrer après une coupure brutale, un disque saturé, une mise à jour de paquet, une modification de my.cnf ou parce que le noyau a tué mysqld faute de mémoire.
Sur Debian et Ubuntu, le service s’appelle mysql ou mariadb selon le paquet installé (les deux noms fonctionnent souvent). Ne supprimez jamais le contenu de /var/lib/mysql pour « repartir de zéro » : c’est là que vivent vos données. Les étapes 1 à 4 écartent les causes simples, les étapes 5 à 7 traitent la corruption.
Lire le statut et le journal d’erreurs
Lancez systemctl status mysql --no-pager -l (ou mariadb), puis journalctl -u mysql -n 100 --no-pager. Le journal d’erreurs de la base se trouve souvent dans /var/log/mysql/error.log ; la variable log_error de la configuration donne l’emplacement exact. Cherchez la première ligne d’erreur du dernier démarrage, pas la dernière du fichier : les lignes suivantes ne sont que des conséquences. Des mentions comme No space left on device, Can't create/write to file, Cannot allocate memory ou Unknown variable désignent déjà la cause.
Vérifier le disque, les inodes et la mémoire
Contrôlez df -h et df -i : une base qui ne peut plus écrire dans son dossier, ou dans /tmp, s’arrête ou refuse de repartir. Libérez de la place en suivant le guide sur le disque plein. Regardez ensuite si le noyau a tué le processus : journalctl -k | grep -i -E "out of memory|killed process". Si mysqld ou mariadbd apparaît, la mémoire est en cause : réduisez innodb_buffer_pool_size et le nombre de connexions, et traitez la saturation avec le guide sur un serveur surchargé.
Écarter un processus fantôme, un port occupé ou un droit incorrect
Vérifiez qu’aucune instance ne tourne déjà avec ps aux | grep -E "mysqld|mariadbd" et ss -tlnp | grep 3306. Un processus resté actif bloque les fichiers de données. Contrôlez ensuite le propriétaire du dossier de données : ls -ld /var/lib/mysql doit montrer mysql mysql. Une restauration faite en root a parfois laissé des fichiers appartenant à root ; corrigez ciblé avec chown -R mysql:mysql /var/lib/mysql. Sur Ubuntu, un profil AppArmor peut aussi refuser l’accès à un datadir déplacé, ce que journalctl -k | grep -i apparmor révèle.
Chercher une erreur de configuration
Si le journal parle d’une variable ou d’une option inconnue, listez les fichiers modifiés récemment avec ls -lt /etc/mysql/ /etc/mysql/*.d/. Une option retirée d’une version à l’autre, une faute de frappe ou une valeur démesurée empêche le démarrage. Mettez en commentaire la ligne fautive, ou retirez le dernier fichier ajouté en le déplaçant hors du dossier (sans le supprimer), puis relancez systemctl start mysql.
Sauvegarder le dossier de données avant toute réparation
Avant d’essayer quoi que ce soit sur des tables corrompues, arrêtez le service (systemctl stop mysql) et copiez tout le dossier : cp -a /var/lib/mysql /sauvegarde/mysql-datadir-copie vers un disque disposant de la place nécessaire (comparez avec du -sh /var/lib/mysql). Cette copie est votre filet de sécurité : si une tentative de récupération aggrave l’état, vous repartez de l’original. Copiez-la aussi hors du serveur si les données sont critiques.
Exporter les données avec innodb_force_recovery
Quand le journal signale une corruption (Database page corruption, InnoDB: Assertion failure, init function returned error), ajoutez dans le fichier de configuration, sous [mysqld], la ligne innodb_force_recovery = 1, puis tentez systemctl start mysql. Si le démarrage échoue, passez à 2, puis 3 et ainsi de suite, un seul niveau à la fois. Les niveaux 1 à 3 sont les moins risqués ; à partir du niveau 4, des données peuvent être définitivement perdues. Ce mode sert uniquement à exporter : dès que le service répond, lancez mysqldump --databases base1 base2 > /sauvegarde/export.sql pour chaque base utile, sans écrire dans les tables.
Réinitialiser le datadir et restaurer le dump
Arrêtez le service, déplacez l’ancien dossier (mv /var/lib/mysql /var/lib/mysql.corrompu) sans le supprimer, puis créez un dossier neuf. Sous MariaDB, mysql_install_db --user=mysql --datadir=/var/lib/mysql l’initialise ; sous MySQL 8, mysqld --initialize-insecure --user=mysql. Retirez innodb_force_recovery de la configuration, démarrez le service, sécurisez le compte root, recréez les utilisateurs de vos applications, puis restaurez avec mysql < /sauvegarde/export.sql. Les droits des utilisateurs se recréent à la main avec CREATE USER et GRANT.
Contrôler le résultat et prévenir la récidive
Lancez mysqlcheck --all-databases pour vérifier les tables, puis testez les sites qui utilisent la base. Gardez la copie mysql.corrompu jusqu’à ce que tout fonctionne depuis plusieurs jours. Planifiez ensuite un export régulier avec mysqldump, stocké hors du serveur (voir la page sur la sauvegarde), et surveillez l’espace disque et la mémoire. Côté WordPress, le guide sur l’erreur de connexion à la base de données vérifie les identifiants une fois la base revenue.
Questions fréquentes
Pourquoi MySQL ne démarre-t-il pas après un redémarrage du serveur ?
Les causes principales sont un disque plein, un processus tué par manque de mémoire, une option de configuration invalide, des droits modifiés sur /var/lib/mysql ou une corruption après coupure brutale. Le journal d’erreurs indique laquelle : lisez la première erreur du dernier démarrage.
Où se trouve le journal d’erreurs de MySQL ou MariaDB ?
Sur Debian et Ubuntu, il s’agit souvent de /var/log/mysql/error.log, mais l’emplacement exact dépend de la variable log_error. À défaut, journalctl -u mysql ou journalctl -u mariadb affiche les messages du démarrage via systemd.
Comment utiliser innodb_force_recovery sans perdre de données ?
Faites d’abord une copie complète du datadir, puis commencez par la valeur 1 et montez d’un niveau à la fois. Le mode permet seulement de lire et d’exporter avec mysqldump. Au niveau 4 et au-delà, une perte de données devient possible : la copie préalable est donc indispensable.
Puis-je réparer une table InnoDB corrompue avec REPAIR TABLE ?
Non, REPAIR TABLE ne concerne pas InnoDB. Pour ce moteur, la méthode consiste à démarrer en mode de récupération, exporter les données avec mysqldump, recréer le dossier de données puis restaurer le dump. Une sauvegarde récente reste la meilleure protection.
Quelle différence entre MySQL et MariaDB pour ce dépannage ?
Les commandes sont presque identiques : systemctl, journal d’erreurs, innodb_force_recovery, mysqldump. Les noms du service (mysql ou mariadb), du binaire (mysqld ou mariadbd) et la commande d’initialisation du datadir diffèrent, comme les journaux par défaut.
Sources
- InnoDB Recovery Modes — MariaDB Knowledge Base
- Error Log — MariaDB Knowledge Base
- mariadb-dump / mysqldump — MariaDB Knowledge Base