web-dev-qa-db-fra.com

Pourquoi les fichiers journaux de bin MySQL existent-ils toujours après une purge ou un vidage?

J'ai utilisé PURGE BINARY LOGS ainsi que FLUSH LOGS, mais le répertoire mysql contient toujours ces fichiers:

mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index

Y a-t-il une raison pour laquelle l'utilisation des commandes ne fonctionne pas? Ces fichiers prennent beaucoup de place. Je voudrais m'en débarrasser en toute sécurité.

mysqlbinlogmysqlbinlog
12
lamp_scaler

Le PURGE BINARY LOGS l'instruction supprime tous les fichiers journaux binaires répertoriés dans le fichier d'index des journaux avant le nom ou l'horodatage du fichier journal spécifié. Les fichiers journaux supprimés sont également supprimés de la liste enregistrée dans le fichier d'index, de sorte que le fichier journal donné devient le premier de la liste.

J'espère que vous avez purgé les journaux binaires jusqu'à mysql-bin.000019 en utilisant la commande

PURGE BINARY LOGS TO 'mysql-bin.000019';

Si vous devez purger tous les journaux, faites comme

PURGE BINARY LOGS TO 'mysql-bin.000025';

Cela supprimera les journaux binaires jusqu'à mysql-bin.000025.

[~ # ~] mise à jour [~ # ~]

Tu peux essayer

RESET MASTER;

RESET MASTER Supprime tous les fichiers journaux binaires répertoriés dans le fichier d'index, réinitialise le fichier d'index du journal binaire pour qu'il soit vide et crée un nouveau fichier journal binaire

Les effets de RESET MASTER diffèrent de ceux de PURGE BINARY LOGS de 2 façons:

  1. RESET MASTER supprime tous les fichiers journaux binaires répertoriés dans le fichier d'index, ne laissant qu'un seul fichier journal binaire vide avec un suffixe numérique de .000001, tandis que la numérotation n'est pas réinitialisée par PURGE BINARY LOGS.

  2. RESET MASTER n'était pas destiné à être utilisé pendant l'exécution d'esclaves de réplication. Le comportement de RESET MASTER lorsqu'il est utilisé pendant que les esclaves sont en cours d'exécution n'est pas défini (et donc non pris en charge), tandis que PURGE BINARY LOGS peut être utilisé en toute sécurité pendant l'exécution des esclaves de réplication.

CAVEAT par RolandoMySQLDBA

Si vous exécutez RESET MASTER avec les esclaves connectés et en cours d'exécution, le thread IO de chaque esclave perdra immédiatement sa place. La réplication est donc interrompue et vous devrez passer du temps à récupérer les données de tous les esclaves à nouveau synchronisés) Si vous souhaitez supprimer en toute sécurité les journaux binaires d'un maître sans rompre l'intégrité de la réplication, voici ce que vous faites:

  • Courir SHOW SLAVE STATUS\G sur chaque esclave.
  • Prenez note de Relay_Master_Log_File. Il s'agit du journal binaire dont la dernière instruction a été exécutée avec succès dans l'esclave).
  • De tous les écrans de SHOW SLAVE STATUS\G, déterminez Relay_Master_Log_File est le plus ancien (par exemple, 'mysql-bin.00123').
  • Tu peux courir PURGE BINARY LOGS TO 'mysql-bin.00123'; Aucun des esclaves ne perdra sa place.

L'effet global? Cela laissera des journaux binaires sur le maître dont les instructions n'ont pas encore été exécutées sur tous les esclaves.

10
Abdul Manaf

Je ne sais pas si c'est ce qui vous est arrivé, mais dans mon cas, MySQL avait cessé de "cycler" les journaux et le fichier mysql-bin.index était devenu "corrompu" avec des entrées de fichier binlog invalides.

Plus précisément, le fichier d'index avait commencé à mysql-bin.000001 et était arrivé à mysql-bin.000220 mais avait ensuite repris en quelque sorte à partir de 001. Lorsque j'ai comparé cela aux fichiers sur mon serveur, j'ai pu voir que j'avais des fichiers de 001 à 022.

Au début, j'ai essayé PURGE LOGS TO 'mysql-bin.000022'; mais cela n'a pas fonctionné.

Finalement, j'ai arrêté MySQL et modifié manuellement le fichier d'index jusqu'à ce qu'il corresponde aux fichiers que j'avais sur mon serveur. Lorsque j'ai redémarré MySQL, il a nettoyé les fichiers binlog pour respecter le expire_logs_days paramètre et a recommencé à fonctionner normalement.

5
sysadmiral

Dans mon cas PURGE BINARY ne supprimait simplement rien.

J'avais ma partition à 100% d'utilisation (j'ai dû nettoyer un peu mon journal de requêtes lentes pour qu'il y ait assez d'espace pour que mysql soit redémarré), donc la première chose que j'ai faite a été de changer /etc/my.cnf pour commenter la ligne log-bin=mysql-bin (il n'était plus nécessaire sur ce serveur et j'avais oublié de le supprimer), puis j'ai redémarré mysql (cela était nécessaire car il y avait des requêtes en file d'attente qui empêchaient PURGE BINARY d'être exécuté).

Après cela, j'ai couru PURGE BINARY mais rien ne s'est passé. J'ai donc lu le manuel et j'ai découvert que:

Cette instruction n'a aucun effet si le serveur n'a pas été démarré avec l'option --log-bin pour activer la journalisation binaire.

J'ai donc réactivé log-bin=mysql-bin dans mon /etc/my.cnf, redémarré, PURGE les fichiers (avec succès maintenant), commente à nouveau la ligne, puis redémarre. Après cela, les fichiers ont été supprimés et ne sont plus créés.

3
carla

Cela fonctionne pour moi: (version du serveur MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Supprime tous les journaux binaires de mon système.

2
grobmotoriker

Vous pouvez facilement supprimer [~ # ~] tous les journaux [~ # ~] avec:

PURGE BINARY LOGS BEFORE NOW();

Ou remplacez func NOW () par n'importe quelle date entre guillemets:

PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';

Ou vous pouvez automatiser cette action avec expire_logs_days = 10 dans my.cnf. Par défaut expire_logs_days est 0 = ne jamais supprimer les journaux.

( source )

0
c ccx