MySQL : gérer, purger ou désactiver les binary logs

Sur un serveur MySQL, les binary logs peuvent vite prendre beaucoup de place. Il n’est pas rare de découvrir plusieurs dizaines, voire plusieurs centaines de gigaoctets de fichiers binlog.* après quelques mois d’activité.

Ces fichiers ne sont pas des logs applicatifs classiques. Ils enregistrent les modifications effectuées sur les bases de données, afin de permettre la réplication, certaines stratégies de sauvegarde, et la restauration à un point précis dans le temps.

En clair : avant de les supprimer ou de les désactiver, il faut comprendre à quoi ils servent sur votre serveur. Sinon, vous risquez de récupérer de l’espace disque tout en cassant votre stratégie de backup. Mauvais troc.

À quoi servent les binary logs MySQL ?

Les binary logs, ou journaux binaires, enregistrent les événements qui modifient les données : INSERT, UPDATE, DELETE, créations de tables, modifications de structure, etc.

Ils servent principalement à trois choses :

• répliquer les modifications vers un ou plusieurs serveurs replicas ;
• rejouer des transactions après une restauration de sauvegarde ;
• faire du point-in-time recovery, c’est-à-dire restaurer une base jusqu’à un instant précis.

Si votre serveur MySQL est autonome, sans réplication, sans cluster, sans sauvegarde incrémentale basée sur les binary logs, et sans besoin de restauration fine, vous pouvez envisager de désactiver les binary logs.

En revanche, si vous utilisez la réplication, MySQL Router, un cluster, un service de backup qui lit les binlogs, ou une stratégie de restauration avancée, ne les désactivez pas. Dans ce cas, configurez plutôt une rétention raisonnable.

Identifier les binary logs sur le serveur

Commencez par vérifier si les binary logs sont activés :

sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"Code language: JavaScript (javascript)

Si la valeur est ON, MySQL écrit des binary logs.

Affichez ensuite leur emplacement :

sudo mysql -e "SHOW VARIABLES LIKE 'log_bin_basename';"Code language: JavaScript (javascript)

Vous pouvez aussi lister les binary logs connus par MySQL :

sudo mysql -e "SHOW BINARY LOGS;"Code language: JavaScript (javascript)

Pour mesurer l’espace utilisé sur le disque, adaptez le chemin selon la sortie précédente. Sur Debian et Ubuntu, les données MySQL se trouvent souvent dans /var/lib/mysql :

sudo du -ch /var/lib/mysql/binlog.* 2>/dev/null | tail -n 1Code language: JavaScript (javascript)

Si vos fichiers s’appellent plutôt mysql-bin.000001, utilisez :

sudo du -ch /var/lib/mysql/mysql-bin.* 2>/dev/null | tail -n 1Code language: JavaScript (javascript)

Ne supprimez pas les fichiers binlog à la main

Premier réflexe à éviter : supprimer les fichiers directement avec rm.

# Mauvaise idée.
sudo rm /var/lib/mysql/binlog.*Code language: PHP (php)

MySQL maintient un index interne de ses binary logs. Si vous supprimez les fichiers à la main, l’index peut ne plus correspondre aux fichiers présents sur le disque. Résultat : erreurs, réplication cassée, purge confuse, et dépannage franchement pénible.

Utilisez toujours les commandes SQL prévues pour cela, notamment PURGE BINARY LOGS.

Purger les anciens binary logs proprement

Pour supprimer les binary logs anciens, connectez-vous à MySQL et utilisez PURGE BINARY LOGS.

Par exemple, pour supprimer tous les binary logs antérieurs au 1er mai 2026 :

sudo mysql -e "PURGE BINARY LOGS BEFORE '2026-05-01 00:00:00';"Code language: JavaScript (javascript)

Vous pouvez aussi purger avant un fichier précis :

sudo mysql -e "PURGE BINARY LOGS TO 'binlog.000120';"Code language: JavaScript (javascript)

Cette commande supprime les fichiers antérieurs au fichier indiqué. Elle ne supprime pas le fichier nommé dans la commande.

Après purge, vérifiez la liste restante :

sudo mysql -e "SHOW BINARY LOGS;"Code language: JavaScript (javascript)

Puis vérifiez l’espace disque :

df -h
sudo du -sh /var/lib/mysqlCode language: JavaScript (javascript)

Attention si vous utilisez la réplication

Si le serveur est une source de réplication, ne purgez pas les binary logs avant d’avoir vérifié que les replicas les ont bien lus.

Sur chaque replica, vérifiez l’état de réplication :

SHOW REPLICA STATUS\G

Sur d’anciennes versions ou anciennes documentations, vous verrez aussi :

SHOW SLAVE STATUS\G

Ne purgez jamais un binary log dont un replica a encore besoin. Si vous le faites, la réplication peut s’arrêter avec une erreur du type “source has purged binary logs containing GTIDs that the replica requires”. Et là, la journée devient tout de suite moins agréable.

Configurer une rétention automatique des binary logs

La meilleure solution n’est généralement pas de désactiver les binary logs, mais de définir une durée de conservation raisonnable.

MySQL utilise le paramètre binlog_expire_logs_seconds pour définir l’âge maximal des binary logs. Par exemple, pour conserver 7 jours de logs :

sudo mysql -e "SET PERSIST binlog_expire_logs_seconds = 604800;"Code language: JavaScript (javascript)

Pour conserver 14 jours :

sudo mysql -e "SET PERSIST binlog_expire_logs_seconds = 1209600;"Code language: JavaScript (javascript)

Pour conserver 30 jours :

sudo mysql -e "SET PERSIST binlog_expire_logs_seconds = 2592000;"Code language: JavaScript (javascript)

Vérifiez ensuite la valeur active :

sudo mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"Code language: JavaScript (javascript)

Sur MySQL 8.4, la documentation indique que la durée d’expiration par défaut des binary logs est de 30 jours. Elle précise aussi que les fichiers peuvent être supprimés automatiquement au démarrage du serveur ou lors d’un flush des binary logs.

Pour déclencher une rotation immédiate, vous pouvez lancer :

sudo mysql -e "FLUSH BINARY LOGS;"Code language: JavaScript (javascript)

Si vous préférez configurer cette valeur dans un fichier, ajoutez-la sous [mysqld] :

[mysqld]
binlog_expire_logs_seconds = 604800

Puis redémarrez MySQL :

sudo systemctl restart mysql

Sur une source de réplication, choisissez une rétention supérieure au retard maximal possible des replicas. Si un replica peut rester éteint trois jours, ne gardez pas seulement deux jours de binary logs.

Désactiver les binary logs sous MySQL

Si vous êtes certain que votre serveur ne dépend pas des binary logs, vous pouvez les désactiver.

Sur Ubuntu ou Debian, éditez le fichier de configuration MySQL :

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Ajoutez cette directive sous [mysqld] :

[mysqld]
skip-log-binCode language: CSS (css)

Vous pouvez aussi utiliser l’option équivalente :

[mysqld]
disable-log-binCode language: CSS (css)

Ensuite, redémarrez MySQL :

sudo systemctl restart mysql

Vérifiez que les binary logs sont bien désactivés :

sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"Code language: JavaScript (javascript)

La valeur doit être OFF.

SET sql_log_bin = 0 ne désactive pas les binary logs globalement

On voit parfois cette commande conseillée :

SET sql_log_bin = 0;

Elle ne désactive pas les binary logs du serveur. Elle désactive seulement la journalisation binaire pour la session MySQL courante.

Elle peut servir lors d’une importation ponctuelle que vous ne voulez pas écrire dans les binary logs, mais elle ne règle pas le problème d’accumulation des fichiers binlog.* sur le disque.

Pour désactiver les binary logs du serveur, il faut une option de démarrage comme skip-log-bin ou disable-log-bin, puis un redémarrage de MySQL.

Nettoyer les anciens binary logs après désactivation

Après désactivation et redémarrage, vérifiez d’abord que MySQL ne journalise plus :

sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"Code language: JavaScript (javascript)

Si la valeur est bien OFF, les anciens fichiers binlog ne seront plus utilisés pour écrire de nouveaux événements. Cependant, ils peuvent encore être présents sur le disque.

Si PURGE BINARY LOGS ne fonctionne plus parce que le serveur a été démarré sans binary logging, arrêtez MySQL avant de supprimer les anciens fichiers. C’est la méthode la plus prudente.

sudo systemctl stop mysql

sudo ls -lh /var/lib/mysql/binlog.* 2>/dev/null
sudo rm -f /var/lib/mysql/binlog.*

sudo systemctl start mysqlCode language: JavaScript (javascript)

Adaptez le motif si vos fichiers s’appellent mysql-bin.* :

sudo systemctl stop mysql

sudo ls -lh /var/lib/mysql/mysql-bin.* 2>/dev/null
sudo rm -f /var/lib/mysql/mysql-bin.*

sudo systemctl start mysqlCode language: JavaScript (javascript)

Ne lancez cette suppression manuelle qu’après avoir désactivé les binary logs et arrêté MySQL. Si les binary logs sont encore actifs, utilisez PURGE BINARY LOGS, pas rm.

Réduire la taille des binary logs sans les désactiver

Si vous avez besoin des binary logs, mais qu’ils grossissent trop vite, vous pouvez agir sur la rétention et parfois sur leur contenu.

Commencez par une rétention plus courte :

sudo mysql -e "SET PERSIST binlog_expire_logs_seconds = 604800;"Code language: JavaScript (javascript)

Vous pouvez aussi vérifier le format utilisé :

sudo mysql -e "SHOW VARIABLES LIKE 'binlog_format';"
sudo mysql -e "SHOW VARIABLES LIKE 'binlog_row_image';"Code language: JavaScript (javascript)

Sur des charges très orientées écriture, ROW avec binlog_row_image = FULL peut générer des binary logs volumineux. Dans certains contextes, binlog_row_image = MINIMAL réduit le volume, mais ce réglage doit être évalué sérieusement avant production, surtout avec réplication, audit, outils de CDC ou restauration avancée.

Dans la plupart des cas, régler correctement binlog_expire_logs_seconds suffit déjà à éviter que le disque se remplisse.

Checklist rapide : récupérer de l’espace disque

Voici la séquence que j’utilise pour diagnostiquer et corriger un serveur MySQL saturé par les binary logs :

# 1. Vérifier l’espace disque.
df -h

# 2. Vérifier si les binary logs sont activés.
sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"

# 3. Trouver leur emplacement.
sudo mysql -e "SHOW VARIABLES LIKE 'log_bin_basename';"

# 4. Lister les binary logs connus par MySQL.
sudo mysql -e "SHOW BINARY LOGS;"

# 5. Mesurer l’espace utilisé.
sudo du -ch /var/lib/mysql/binlog.* 2>/dev/null | tail -n 1

# 6. Purger proprement les anciens logs.
sudo mysql -e "PURGE BINARY LOGS BEFORE '2026-05-01 00:00:00';"

# 7. Configurer une rétention automatique de 7 jours.
sudo mysql -e "SET PERSIST binlog_expire_logs_seconds = 604800;"

# 8. Déclencher une rotation.
sudo mysql -e "FLUSH BINARY LOGS;"

# 9. Vérifier le résultat.
sudo mysql -e "SHOW BINARY LOGS;"
df -hCode language: PHP (php)

Checklist rapide : désactiver les binary logs

Si le serveur n’utilise ni réplication, ni restauration point-in-time, ni outil de backup dépendant des binlogs, voici la séquence de désactivation :

# 1. Modifier la configuration.
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

# Ajouter sous [mysqld] :
# skip-log-bin

# 2. Redémarrer MySQL.
sudo systemctl restart mysql

# 3. Vérifier que les binary logs sont désactivés.
sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"

# 4. Si log_bin = OFF, arrêter MySQL avant nettoyage manuel éventuel.
sudo systemctl stop mysql

# 5. Supprimer les anciens fichiers, en adaptant le motif.
sudo rm -f /var/lib/mysql/binlog.*

# 6. Redémarrer MySQL.
sudo systemctl start mysql

# 7. Vérifier l’espace disque.
df -hCode language: PHP (php)

Conclusion

Les binary logs MySQL peuvent remplir un disque très vite, surtout sur un serveur actif. Mais ils ne sont pas inutiles par défaut : ils servent à la réplication et aux restaurations avancées.

La meilleure approche consiste donc à choisir entre deux stratégies claires.

• Si vous avez besoin des binary logs : gardez-les, mais configurez une rétention avec binlog_expire_logs_seconds.
• Si vous n’en avez pas besoin : désactivez-les avec skip-log-bin, redémarrez MySQL, puis nettoyez les anciens fichiers avec prudence.

Dans tous les cas, ne supprimez pas les fichiers binlog à chaud avec rm pendant que MySQL les utilise. Utilisez PURGE BINARY LOGS lorsque les binary logs sont actifs, et ne passez à la suppression manuelle qu’après désactivation et arrêt du service.

Le vrai bon réflexe n’est donc pas “désactiver les logs binaires”. C’est plutôt : comprendre leur rôle, fixer une rétention, et éviter que MySQL transforme discrètement votre disque en musée du binlog.

Sources

• Documentation MySQL 8.4 : maintenance des fichiers logs
• Documentation MySQL 8.4 : options et variables des binary logs
• Documentation MySQL 8.4 : PURGE BINARY LOGS
• Documentation MySQL 8.4 : réplication
• Documentation MySQL 8.4 : point-in-time recovery avec les binary logs

Report a typo