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.
