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é.

L' PURGE BINARY LOGSinstruction supprime tous les fichiers journaux binaires répertoriés dans le fichier d'index de journaux avant le nom de fichier journal ou l'horodatage 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'à l' mysql-bin.000019aide de 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 des journaux binaires pour qu'il soit vide et crée un nouveau fichier journal binaire

Les effets de RESET MASTERdiffèrent de ceux de PURGE BINARY LOGS de 2 manières principales:

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 MASTERn'était pas destiné à être utilisé pendant l'exécution d'esclaves de réplication. Le comportement de RESET MASTERlorsqu'il est utilisé pendant que les esclaves sont en cours d'exécution n'est pas défini (et donc non pris en charge), alors qu'il PURGE BINARY LOGSpeut être utilisé en toute sécurité pendant que les esclaves de réplication sont en cours d'exécution.

CAVEAT par RolandoMySQLDBA

Si vous exécutez RESET MASTERavec des esclaves connectés et en cours d'exécution, le fil d'E / S de chaque esclave perdra immédiatement sa place. La réplication est donc interrompue et vous devrez passer du temps à récupérer à nouveau les données de tous les esclaves. 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:

• Exécutez SHOW SLAVE STATUS\Gsur 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).
• À partir de tous les affichages de SHOW SLAVE STATUS\G, déterminez lequel Relay_Master_Log_Fileest le plus ancien (par exemple, 'mysql-bin.00123').
• Vous pouvez exécuter 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.

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é.

À la fin, 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_daysparamètre et a recommencé à fonctionner normalement.

Dans mon cas, je PURGE BINARYne supprimais 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 suffisamment d'espace pour que mysql soit redémarré), donc la première chose que j'ai faite a été de changer /etc/my.cnfpour commenter la ligne log-bin=mysql-bin(ce n'était pas 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 attente qui empêchaient PURGE BINARYd'être exécutées).

Après cela, j'ai couru PURGE BINARYmais il ne s'est rien 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.

Alors je réactivées log-bin=mysql-bindans mes /etc/my.cnf, remis en marche, purgés les fichiers (avec succès maintenant), a commenté la ligne à nouveau, puis redémarré. Après cela, les fichiers ont été supprimés et ne sont plus créés.

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.

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 = 10my.cnf. Par défaut expire_logs_days est 0 = ne jamais supprimer les journaux.

( source )