Un log binaire contient toutes les requêtes qui modifient les données et se voit utilisé par le(s) esclave(s) lors d’une réplication.
Dans la documentation on peut lire que l’on peut "effacer tous les fichiers de log avec la commande RESET MASTER, ou seulement certains d’entre eux avec PURGE MASTER LOGS".
mysql > PURGE BINARY LOGS TO 'mysql-bin.0020';
mysql > PURGE BINARY LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);
Ces commandes effacent tous les logs binaires listés dans l’index de logs, qui sont antérieurs au log (dans l’exemple antérieurs au log ’mysql-bin.0020’) ou à la date indiqué (dans l’exemple antérieurs de 10 jours à la date courante).
Ceux-ci sont alors supprimés de l’indexation - le log éventuel donné en paramètre devient alors le premier de la liste.
En théorie, au prochain redémarrage du serveur MySQL ou à la prochaine commande "FLUSH LOGS", MySQL doit faire tourner les logs, crée un nouveau fichier de log binaires et supprimer les anciens logs binaires selon la variable système " expire_logs_days " présente dans le fichier de configuration "my.cnf" [1].
Seulement en pratique, ce n’est pas toujours le cas [2].
Au moins une alternative se présente et fonctionne (pour moi en tout cas
) :
- Arrêter MySQL
- effacer les vieux log binaires à la main :
find /var/log/mysql/hostname-bin.* -mtime +10 -exec rm {}\; - reconstruire l’index des binaires
ls /var/lib/mysql/ > mysql-bin.index - redémarrer MySQL
Et hop, ça c’est fait… le mieux serait de faire un script et de croner tout ça non ? Hum, demain…![]()
Tags
Infos