Eu usei PURGE BINARY LOGS e FLUSH LOGS, mas o diretório mysql ainda contém esses arquivos:

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

Existe uma razão pela qual o uso dos comandos não está funcionando? Esses arquivos estão ocupando muito espaço. Eu gostaria de me livrar deles com segurança.

A PURGE BINARY LOGSinstrução exclui todos os arquivos de log binários listados no arquivo de índice de log antes do nome ou carimbo de data / hora do arquivo de log especificado. Os arquivos de log excluídos também são removidos da lista registrada no arquivo de índice, para que o arquivo de log especificado se torne o primeiro na lista.

Espero que você tenha removido logs binários até mysql-bin.000019usando o comando

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

Se você precisar limpar todos os logs, faça o seguinte:

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

Isso removerá os logs binários até mysql-bin.000025.

ATUALIZAR

Podes tentar

RESET MASTER;

RESET MASTER Exclui todos os arquivos de log binários listados no arquivo de índice, redefine o arquivo de índice de log binário para ficar vazio e cria um novo arquivo de log binário

Os efeitos de RESET MASTERdiferem dos de PURGE BINARY LOGS de 2 maneiras principais:

1. RESET MASTER remove todos os arquivos de log binários listados no arquivo de índice, deixando apenas um único arquivo de log binário vazio com um sufixo numérico de .000001, enquanto a numeração não é redefinida por PURGE BINARY LOGS.

2. RESET MASTERnão foi projetado para ser usado enquanto os escravos de replicação estiverem em execução. O comportamento de RESET MASTERquando usado enquanto os escravos estão em execução é indefinido (e, portanto, sem suporte), enquanto PURGE BINARY LOGSpode ser usado com segurança enquanto os escravos de replicação estão em execução.

CAVEAT by RolandoMySQLDBA

Se você executar RESET MASTERcom os Slaves conectados e em execução, o thread de E / S de cada escravo perderá imediatamente seu lugar. Portanto, a replicação é interrompida e você terá que gastar tempo obtendo os dados de todos os Slaves sincronizados novamente. Se você deseja excluir com segurança os logs binários de um mestre sem violar a integridade da replicação, eis o que você faz:

• Corra SHOW SLAVE STATUS\Gem cada escravo.
• Tome nota Relay_Master_Log_File. Este é o log binário cuja última instrução foi executada com sucesso no Slave).
• Em todas as exibições de SHOW SLAVE STATUS\G, determine qual Relay_Master_Log_Fileé a mais antiga (por exemplo, 'mysql-bin.00123').
• Você pode executar PURGE BINARY LOGS TO 'mysql-bin.00123';Nenhum dos escravos perderá seu lugar.

O efeito geral? Isso deixará para trás logs binários no Mestre, cujas instruções ainda não foram executadas em todos os escravos.

Não tenho certeza se foi o que aconteceu com você, mas no meu caso o MySQL parou de "dar um ciclo" nos logs e o arquivo mysql-bin.index ficou "corrompido" com entradas inválidas no arquivo binlog.

Especificamente, o arquivo de índice foi iniciado no mysql-bin.000001 e chegou ao mysql-bin.000220, mas, de alguma forma, foi iniciado novamente a partir de 001. Quando comparei isso com os arquivos no meu servidor, pude ver que havia arquivos de 001 a 022

No começo eu tentei, PURGE LOGS TO 'mysql-bin.000022';mas isso não funcionou.

No final, parei o MySQL e editei manualmente o arquivo de índice até que correspondesse aos arquivos que eu tinha no meu servidor. Quando reiniciei o MySQL, ele limpou os arquivos binlog para respeitar a expire_logs_daysconfiguração e começou a funcionar normalmente novamente.

No meu caso, PURGE BINARYsimplesmente não estava excluindo nada.

Eu tive minha partição com 100% de uso (eu tive que limpar um pouco meu log de slowqueries para que houvesse espaço suficiente para o mysql ser reiniciado), então a primeira coisa que fiz foi mudar /etc/my.cnfpara comentar a linha log-bin=mysql-bin(não era necessário neste servidor e esqueci de removê-lo) e reiniciei o mysql (isso era necessário porque havia consultas na fila que impediam a PURGE BINARYexecução).

Depois disso, corri, PURGE BINARYmas nada aconteceu. Então eu li o manual e descobri que:

Esta declaração não terá efeito se o servidor não tiver sido iniciado com a opção --log-bin para ativar o log binário.

Então , reativei log-bin=mysql-binno meu /etc/my.cnf, reiniciei, COMPRIMEI os arquivos (agora com sucesso), comentei a linha novamente e reiniciei. Depois disso, os arquivos foram removidos e não mais criados.

Isso funciona para mim: (versão do servidor MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Remove todos os logs binários do meu sistema.

Você pode excluir facilmente TODOS os logs com:

PURGE BINARY LOGS BEFORE NOW();

Ou substitua func NOW () por qualquer data entre aspas:

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

Ou você pode automatizar essa ação expire_logs_days = 10no my.cnf. Por padrão, expire_logs_days é 0 = nunca exclua logs.

( fonte )