Il y a quelque temps, j’ai eu la mauvaise surprise de constater qu’un site était hors ligne parce que MySQL refusait catégoriquement de redémarrer.

En regardant les logs du serveur, le message était sans appel :

/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! failed!

La partition qui contenait les bases de données était pleine. Et quand MySQL n’a plus assez d’espace pour écrire dans son répertoire de données, ses fichiers temporaires, ses logs, ses redo logs ou ses binlogs, il peut refuser de démarrer, se bloquer, désactiver certains logs ou planter au mauvais moment.

MySQL documente explicitement les erreurs liées au disque plein, comme No space left on device, write failed ou les dépassements de quota. Le manuel MySQL explique que ces conditions peuvent toucher les écritures dans les tables, les fichiers de logs binaires et l’index des binlogs. Voir la documentation MySQL sur les disques pleins.

Voici une procédure moderne pour diagnostiquer et corriger le problème proprement, sans supprimer au hasard des fichiers dans /var/lib/mysql. Parce que supprimer des fichiers InnoDB à la main pour “faire de la place”, c’est rarement une stratégie. C’est plutôt une candidature spontanée à la restauration de backup.

Symptômes d’un MySQL bloqué par manque d’espace disque

Les symptômes peuvent varier selon la version, le moteur de stockage, la distribution et le système d’init. Vous pouvez voir :

• MySQL ou MariaDB refuse de démarrer ;
• systemctl start mysql échoue ;
• systemctl restart mariadb reste bloqué ;
• les sites affichent une erreur de connexion à la base ;
• les logs indiquent No space left on device ;
• les binlogs grossissent jusqu’à saturer la partition ;
• les tables temporaires ne peuvent plus être créées ;
• la partition /, /var, /tmp ou /var/lib/mysql est à 100 % ;
• les inodes sont épuisés même s’il reste de l’espace en Go.

Sur les serveurs modernes, l’erreur peut apparaître dans le log MySQL, les logs MariaDB ou le gestionnaire d’hébergement. Plesk documente par exemple des échecs MySQL/MariaDB lorsque la partition racine, la partition /tmp ou les inodes sont saturés. Voir la note Plesk sur MySQL/MariaDB et le manque d’espace.

Étape 1 : vérifier l’état du service MySQL ou MariaDB

Commencez par identifier le service concerné.

systemctl status mysql --no-pager

Sur MariaDB :

systemctl status mariadb --no-pager

Consultez les derniers logs systemd :

journalctl -u mysql -n 100 --no-pager

ou :

journalctl -u mariadb -n 100 --no-pager

Si le service échoue avec une erreur liée à l’espace disque, vous avez déjà une piste très solide.

Étape 2 : vérifier les partitions avec df

La première commande à lancer est :

df -h

Exemple de sortie problématique :

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.7G  9.7G     0 100% /
tmpfs           984M     0  984M   0% /dev/shm
/dev/sda2       452G  648M  429G   1% /home

Ici, la partition racine / est pleine à 100 %. Si /var/lib/mysql se trouve sur cette partition, MySQL ne peut plus écrire correctement.

Vérifiez explicitement le point de montage de /var/lib/mysql :

df -h /var/lib/mysql

Vérifiez aussi /tmp, car MySQL peut l’utiliser pour certaines opérations temporaires :

df -h /tmp

Une partition peut avoir de l’espace disponible ailleurs sur le serveur, par exemple dans /home, et rester bloquée si /var/lib/mysql est sur une petite partition racine pleine. C’est exactement le genre de situation qui donne envie de redessiner le partitionnement après coup. Avec un café très fort.

Étape 3 : vérifier les inodes

Un serveur peut afficher encore de l’espace disponible en Go, mais ne plus avoir d’inodes disponibles. Dans ce cas, il ne peut plus créer de nouveaux fichiers.

df -i

Vérifiez spécifiquement la partition MySQL :

df -i /var/lib/mysql

Si IUse% est à 100%, vous avez un problème d’inodes, pas seulement d’espace disque. Cela arrive avec des millions de petits fichiers : sessions, caches, mails, fichiers temporaires, anciennes sauvegardes éclatées, ou répertoires applicatifs mal nettoyés.

Étape 4 : trouver ce qui prend de la place

Pour savoir quels répertoires consomment l’espace sur la partition racine :

du -xhd1 / | sort -h

Le -x évite de traverser les autres systèmes de fichiers montés. C’est utile si /home, /backup ou d’autres partitions sont séparées.

Pour inspecter /var :

du -xhd1 /var | sort -h

Pour inspecter le répertoire MySQL :

du -xhd1 /var/lib/mysql | sort -h

Pour trouver les plus gros fichiers sur la partition racine :

find / -xdev -type f -size +100M -printf '%s %p\n' 2>/dev/null | sort -n | tail -30

Cette commande aide à repérer les gros logs, archives, dumps SQL, backups oubliés, binlogs, fichiers temporaires ou exports qui ont rempli la partition.

Étape 5 : ne supprimez pas les fichiers MySQL au hasard

Quand /var/lib/mysql est énorme, la tentation est forte de supprimer quelques fichiers dans le répertoire de données. Mauvaise idée.

Ne supprimez pas manuellement :

• ibdata1 ;
• ib_logfile* ou fichiers redo logs ;
• undo_* ;
• les fichiers .ibd ;
• les fichiers .frm sur anciens serveurs ;
• les répertoires de bases ;
• les fichiers du data dictionary ;
• les fichiers temporaires InnoDB sans comprendre leur état.

MySQL 8.4 documente les redo logs comme une structure disque utilisée pendant la récupération après crash pour rejouer les modifications incomplètes avant d’accepter les connexions. Les supprimer au mauvais moment peut aggraver fortement la situation. Voir la documentation MySQL sur les redo logs InnoDB.

Libérez d’abord de l’espace ailleurs : logs, caches, vieux dumps, journaux systemd, archives, sauvegardes locales ou fichiers supprimés encore ouverts.

Étape 6 : libérer de l’espace sans casser MySQL

Voici des zones sûres à inspecter avant de toucher aux données MySQL.

Nettoyer le cache APT

apt clean
apt autoclean
apt autoremove --purge

Réduire les logs systemd journal

Vérifiez l’espace pris par journald :

journalctl --disk-usage

Réduisez les journaux à une taille raisonnable :

journalctl --vacuum-size=500M

Ou gardez seulement les journaux récents :

journalctl --vacuum-time=14d

Compresser ou vider les gros logs applicatifs

Listez les gros logs :

find /var/log -type f -size +100M -printf '%s %p\n' | sort -n

Pour vider un log actif sans supprimer le fichier :

truncate -s 0 /var/log/example.log

Vider un fichier de log avec truncate évite parfois de devoir redémarrer immédiatement le service qui l’écrit.

Chercher les dumps SQL oubliés

find / -xdev -type f \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.dump' \) -printf '%s %p\n' 2>/dev/null | sort -n | tail -30

Si vous trouvez des dumps ou backups sur la même partition que MySQL, déplacez-les vers /home, un volume de backup, un stockage externe, ou supprimez-les seulement après vérification.

Nettoyer les fichiers temporaires

du -xhd1 /tmp /var/tmp 2>/dev/null | sort -h

Évitez le rm -rf /tmp/* brutal sur un serveur en production. Certains services peuvent avoir des fichiers temporaires actifs. Supprimez plutôt ce que vous identifiez clairement, ou redémarrez proprement après une fenêtre de maintenance si nécessaire.

Étape 7 : vérifier les fichiers supprimés mais encore ouverts

Cas très fréquent : vous supprimez un gros fichier, mais df -h indique toujours que le disque est plein. Cela arrive lorsqu’un processus garde encore le fichier ouvert.

Vérifiez les fichiers supprimés encore ouverts :

lsof +L1

Ou, si la sortie est trop longue :

lsof +L1 | sort -k7 -n | tail -30

Ce problème est bien connu côté Linux : un fichier supprimé peut continuer à occuper de l’espace tant que le processus qui l’a ouvert n’est pas arrêté ou rechargé. Des discussions techniques historiques recommandent justement lsof | grep deleted ou lsof +L1 pour repérer ces fichiers. Voir cette discussion Server Fault.

Une fois le processus identifié, redémarrez ou rechargez le service concerné. Si c’est nginx, Apache, PHP-FPM, MySQL ou un agent de logs, faites-le proprement.

Étape 8 : gérer les binlogs MySQL proprement

Les binary logs MySQL peuvent prendre beaucoup de place, surtout sur un serveur avec réplication, sauvegardes incrémentales ou beaucoup d’écritures.

Vérifiez leur présence :

ls -lh /var/lib/mysql/*bin* 2>/dev/null

Si MySQL démarre encore, utilisez SQL plutôt que rm. Listez les binlogs :

mysql -e "SHOW BINARY LOGS;"

Purger les binlogs avant une date :

mysql -e "PURGE BINARY LOGS BEFORE '2026-05-01 00:00:00';"

Ou purger jusqu’à un fichier précis :

mysql -e "PURGE BINARY LOGS TO 'mysql-bin.000123';"

Ne purgez pas les binlogs à l’aveugle si vous avez de la réplication, des sauvegardes PITR ou un outil de backup qui s’appuie dessus. Vérifiez d’abord les dépendances.

MySQL rappelle que les logs serveur peuvent prendre beaucoup de place et doivent être maintenus régulièrement. La documentation conseille de sauvegarder et retirer les anciens logs, puis de demander au serveur de repartir sur de nouveaux fichiers si nécessaire. Voir la documentation MySQL sur la maintenance des logs.

Étape 9 : relancer MySQL ou MariaDB

Une fois de l’espace libéré, vérifiez à nouveau :

df -h /var/lib/mysql
df -i /var/lib/mysql

Exemple de sortie saine :

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.7G  2.2G  7.1G  24% /

Relancez MySQL :

systemctl start mysql

Ou MariaDB :

systemctl start mariadb

Si le service était déjà dans un état étrange, utilisez :

systemctl restart mysql

ou :

systemctl restart mariadb

Vérifiez ensuite :

systemctl status mysql --no-pager
mysqladmin ping

MariaDB peut parfois prendre plus de temps à démarrer après un crash ou une saturation disque, notamment pendant la récupération. Sa documentation systemd précise que certaines tâches de récupération peuvent dépasser le délai de démarrage par défaut et provoquer un timeout systemd si elles sont longues. Voir la documentation MariaDB systemd.

Étape 10 : vérifier l’intégrité après redémarrage

Après un redémarrage consécutif à un disque plein, surveillez les logs :

journalctl -u mysql -n 200 --no-pager

ou :

journalctl -u mariadb -n 200 --no-pager

Vérifiez les erreurs MySQL récentes :

grep -iE "error|warning|corrupt|crash|space|full" /var/log/mysql/error.log | tail -100

Le chemin du log varie selon la distribution. Il peut aussi se trouver dans :

/var/log/mysql/mysql.log
/var/log/mysql/mysql.err
/var/log/mariadb/mariadb.log

Vérifiez que MySQL répond :

mysql -e "SELECT VERSION();"

Pour un site WordPress, testez aussi :

wp db check

Si vous voyez des erreurs d’intégrité, arrêtez les suppressions manuelles et préparez une restauration ou une réparation contrôlée. Là, on n’est plus dans le ménage, on est dans l’intervention chirurgicale.

Cas particulier : MySQL démarre mais le disque se remplit aussitôt

Si vous libérez de l’espace mais que la partition se remplit aussitôt, cherchez un processus qui écrit trop vite.

Installez et lancez iotop si disponible :

apt install iotop
iotop -ao

Surveillez les écritures disque :

iostat -xz 1

Surveillez la croissance des gros fichiers :

watch -n 5 "du -xhd1 /var | sort -h"

Les causes fréquentes :

• binlogs MySQL non purgés ;
• slow query log trop bavard ;
• general log activé en production ;
• backup qui écrit sur la même partition ;
• logs applicatifs en boucle ;
• mail queue qui explose ;
• cache qui grossit sans limite ;
• requête ou tâche cron qui génère des fichiers temporaires énormes.

Prévenir le problème : alertes disque

Un disque plein ne devrait pas être découvert parce que MySQL est tombé. Mettez en place une alerte simple au minimum.

Exemple de script basique :

#!/usr/bin/env bash

set -euo pipefail

THRESHOLD=85
EMAIL="admin@example.com"

df -P | awk 'NR>1 {gsub("%","",$5); if ($5+0 >= threshold) print $0}' threshold="$THRESHOLD" | while read -r line; do
    printf 'Disk usage warning on %s:\n%s\n' "$(hostname -f)" "$line" | mail -s "Disk usage warning on $(hostname -f)" "$EMAIL"
done

Placez-le dans une tâche cron, ou mieux, utilisez une vraie solution de monitoring : Netdata, Prometheus, Zabbix, Checkmk, Grafana Cloud, Uptime Kuma avec scripts, ou les alertes de votre hébergeur.

Sur un serveur MySQL, surveillez au minimum :

• l’espace disque ;
• les inodes ;
• la taille de /var/lib/mysql ;
• la taille des binlogs ;
• la taille des logs système ;
• les erreurs MySQL ;
• les sauvegardes locales ;
• la croissance anormale de /tmp.

Prévenir le problème : rotation et rétention des logs MySQL

Vérifiez que vos logs MySQL sont correctement rotatés.

ls -la /etc/logrotate.d/ | grep -i mysql
cat /etc/logrotate.d/mysql-server 2>/dev/null || true
cat /etc/logrotate.d/mariadb 2>/dev/null || true

Vérifiez aussi les binlogs côté MySQL. Sur MySQL récent, regardez la variable de rétention :

mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"

Sur les anciennes versions, la variable pouvait être :

mysql -e "SHOW VARIABLES LIKE 'expire_logs_days';"

Adaptez la rétention à votre stratégie de backup et de réplication. Ne gardez pas 18 mois de binlogs “au cas où” sur une partition de 20 Go. Le “cas où” arrive rarement avant le “plus de place”.

Faut-il déplacer /var/lib/mysql vers une autre partition ?

Si votre partition racine est trop petite, déplacer le datadir MySQL vers un volume plus grand peut être une solution durable. Mais ce n’est pas une opération à faire pendant l’incident, sauf nécessité absolue.

À planifier en maintenance :

• backup complet vérifié ;
• arrêt propre de MySQL ;
• copie avec permissions préservées ;
• mise à jour de datadir ;
• ajustement AppArmor ou SELinux si nécessaire ;
• test de démarrage ;
• test applicatif ;
• rollback documenté.

MySQL documente plusieurs considérations autour du placement des fichiers InnoDB et de l’I/O disque. Le manuel rappelle notamment que l’organisation des fichiers et des disques peut influencer les performances et la gestion de l’espace. Voir la documentation MySQL sur l’I/O disque.

Commandes récapitulatives

Vérifier l’espace disque :

df -h
df -h /var/lib/mysql
df -h /tmp

Vérifier les inodes :

df -i
df -i /var/lib/mysql

Trouver les gros répertoires :

du -xhd1 / | sort -h
du -xhd1 /var | sort -h
du -xhd1 /var/lib/mysql | sort -h

Trouver les gros fichiers :

find / -xdev -type f -size +100M -printf '%s %p\n' 2>/dev/null | sort -n | tail -30

Voir les fichiers supprimés encore ouverts :

lsof +L1

Redémarrer MySQL :

systemctl restart mysql
systemctl status mysql --no-pager
mysqladmin ping

Redémarrer MariaDB :

systemctl restart mariadb
systemctl status mariadb --no-pager
mysqladmin ping

Résumé rapide

Si MySQL ou MariaDB refuse de redémarrer et que vous voyez :

The partition with /var/lib/mysql is too full

ou :

No space left on device

faites ceci :

1. vérifiez df -h /var/lib/mysql ;
2. vérifiez df -i /var/lib/mysql ;
3. identifiez les gros répertoires avec du ;
4. libérez de l’espace hors /var/lib/mysql si possible ;
5. ne supprimez pas les fichiers InnoDB manuellement ;
6. vérifiez les fichiers supprimés encore ouverts avec lsof +L1 ;
7. purgez les binlogs uniquement via MySQL si nécessaire ;
8. relancez le service ;
9. surveillez les logs après démarrage ;
10. mettez en place des alertes disque.

Conclusion

Quand MySQL refuse de redémarrer, le manque d’espace sur la partition qui contient /var/lib/mysql fait partie des premières pistes à vérifier.

La commande df -h permet de confirmer rapidement si une partition est pleine. df -i permet de détecter un épuisement des inodes. Ensuite, du, find et lsof +L1 permettent d’identifier ce qui consomme réellement l’espace.

La règle d’or : libérez de l’espace proprement, mais ne supprimez jamais au hasard les fichiers internes de MySQL. Une fois assez d’espace récupéré, redémarrez le service, vérifiez les logs, puis mettez en place une surveillance pour éviter que l’incident se reproduise.

Un disque plein, c’est rarement une panne spectaculaire. C’est plutôt un serveur qui vous dit, très calmement, qu’il n’a plus de bureau pour poser ses papiers. Et MySQL, lui, a besoin d’un bureau assez grand.

Sources utiles

• MySQL 8.4 Reference Manual : How MySQL Handles a Full Disk
• MySQL 8.4 Reference Manual : Server Log Maintenance
• MySQL 8.4 Reference Manual : InnoDB Redo Log
• MySQL 8.4 Reference Manual : Optimizing Disk I/O
• MariaDB Documentation : systemd

Report a typo