Ho usato PURGE BINARY LOGs e FLUSH LOGS, ma la directory mysql contiene ancora questi file:

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

C'è un motivo per cui l'utilizzo dei comandi non funziona? Questi file occupano molto spazio. Vorrei liberarmene in modo sicuro.

L' PURGE BINARY LOGSistruzione elimina tutti i file di registro binari elencati nel file di indice del registro prima del nome o della data / ora del file di registro specificato. I file di registro eliminati vengono inoltre rimossi dall'elenco registrato nel file indice, in modo che il file di registro specificato diventi il ​​primo nell'elenco.

Spero che tu abbia eliminato i log binari mysql-bin.000019usando il comando

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

Se è necessario eliminare tutti i registri, fare come

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

Ciò rimuoverà i registri binari fino a mysql-bin.000025.

AGGIORNARE

Puoi provare

RESET MASTER;

RESET MASTER Elimina tutti i file di registro binari elencati nel file indice, reimposta il file indice del registro binario come vuoto e crea un nuovo file di registro binario

Gli effetti di RESET MASTERdifferiscono da quelli di PURGE BINARY LOGS in 2 modi chiave:

1. RESET MASTER rimuove tutti i file di registro binari elencati nel file indice, lasciando solo un singolo file di registro binario vuoto con un suffisso numerico di .000001, mentre la numerazione non viene reimpostata da PURGE BINARY LOGS.

2. RESET MASTERnon è stato progettato per essere utilizzato mentre sono in esecuzione slave di replica. Il comportamento di RESET MASTERquando utilizzato mentre gli slave sono in esecuzione non è definito (e quindi non supportato), mentre PURGE BINARY LOGSpuò essere utilizzato in modo sicuro mentre gli slave di replica sono in esecuzione.

CAVEAT di RolandoMySQLDBA

Se corri RESET MASTERcon gli slave collegati e funzionanti, il thread IO di ogni slave perderà immediatamente il suo posto. La replica viene quindi interrotta e dovrai dedicare del tempo a sincronizzare nuovamente i dati su tutti gli Slave. Se si desidera eliminare in modo sicuro i registri binari da un master senza interrompere l'integrità della replica, ecco cosa fare:

• Esegui SHOW SLAVE STATUS\Gsu ogni slave.
• Prendi nota di Relay_Master_Log_File. Questo è il registro binario la cui ultima istruzione è stata eseguita correttamente nello Slave).
• Da tutti i display di SHOW SLAVE STATUS\G, determinare quale Relay_Master_Log_Fileè il più vecchio (ad esempio, 'mysql-bin.00123').
• È possibile eseguire PURGE BINARY LOGS TO 'mysql-bin.00123';Nessuno degli schiavi perderà il suo posto.

L'effetto complessivo? Questo lascerà dietro i registri binari sul Master le cui dichiarazioni che non sono state ancora eseguite su tutti gli Slave.

Non sono sicuro se questo è quello che ti è successo, ma nel mio caso MySQL aveva smesso di "ciclare" i log e il file mysql-bin.index si era "corrotto" con voci di file binlog non valide.

In particolare, il file di indice era stato avviato da mysql-bin.000001 ed era arrivato a mysql-bin.000220, ma in qualche modo era stato riavviato da 001. Quando ho confrontato questo con i file sul mio server, ho potuto vedere che avevo file da 001 a 022.

All'inizio ci ho provato PURGE LOGS TO 'mysql-bin.000022';ma questo non ha funzionato.

Alla fine ho fermato MySQL e modificato manualmente il file indice fino a quando non corrispondeva ai file che avevo sul mio server. Quando ho riavviato MySQL, ho ripulito i file binlog per rispettare le expire_logs_daysimpostazioni e ho ricominciato a funzionare normalmente.

Nel mio caso PURGE BINARYsemplicemente non stava cancellando nulla.

Ho avuto la mia partizione al 100% di utilizzo (ho dovuto ripulire un po 'il mio registro delle slowqueries in modo che ci fosse abbastanza spazio per mysql per essere riavviato), quindi la prima cosa che ho fatto è stata cambiare /etc/my.cnfper commentare la riga log-bin=mysql-bin(non era necessario in questo server e mi ero dimenticato di rimuoverlo), quindi ho riavviato mysql (questo era necessario perché c'erano delle code in coda che impedivano PURGE BINARYl'esecuzione).

Dopo quello, ho corso PURGE BINARYma non è successo niente. Quindi ho letto il manuale e ho scoperto che:

Questa affermazione non ha alcun effetto se il server non è stato avviato con l'opzione --log-bin per abilitare la registrazione binaria.

Quindi ho riabilitato log-bin=mysql-binnel mio /etc/my.cnf, riavviato, PURGATO i file (con successo ora), ho commentato di nuovo la linea e poi riavviato. Successivamente, i file sono stati rimossi e non più creati.

Questo funziona per me: (versione del server MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Rimuove tutti i registri binari sul mio sistema.

Puoi eliminare facilmente TUTTI i log con:

PURGE BINARY LOGS BEFORE NOW();

O sostituisci funzioni NOW () con qualsiasi data tra virgolette:

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

Oppure puoi automatizzare questa azione con expire_logs_days = 10in my.cnf. Per impostazione predefinita expire_logs_days è 0 = non eliminare mai i registri.

( fonte )