Início / dba / Perguntas / 47046
Accepted
lamp_scaler
Asked: 2013-07-27 00:20:49 +0800 CST

Por que os arquivos de log do MySQL ainda existem após uma limpeza ou liberação?

  • 772

Eu usei PURGE BINARY LOGS assim como FLUSH LOGS, mas o diretório mysql ainda contém estes 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.

mysql binlog

5 respostas

  1. Best Answer

    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 fornecido se torne o primeiro da lista.

    Espero que você tenha limpado os logs binários mysql-bin.000019usando o comando

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

    Se você precisar limpar todos os logs, faça como

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

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

    ATUALIZAR

    Podes tentar

    RESET MASTER;

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

    Os efeitos deRESET MASTER diferem daqueles de PURGE BINARY LOGS de 2 maneiras principais:

    1. RESET MASTERremove 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 0,000001, enquanto a numeração não é redefinida por PURGE BINARY LOGS.

    2. RESET MASTERnão foi planejado para ser usado enquanto quaisquer 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, não suportado), enquantoPURGE BINARY LOGS pode ser usado com segurança enquanto os escravos de replicação estão em execução.

    CAVEAT por RolandoMySQLDBA

    Se você correrRESET MASTER com Slaves conectados e em execução, o IO Thread de cada Slave perderá imediatamente seu lugar. A replicação é então quebrada e você terá que gastar tempo obtendo os dados em todos os Slaves sincronizados novamente. Se você deseja excluir com segurança os logs binários de um mestre sem quebrar a integridade da replicação, faça o seguinte:

    • CorreSHOW SLAVE STATUS\G em cada escravo.
    • Tome nota deRelay_Master_Log_File . Este é o log binário cuja última instrução foi executada com sucesso no Slave).
    • De todas as exibições de SHOW SLAVE STATUS\G, determine quaisRelay_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á logs binários no Master cujas instruções ainda não foram executadas em todos os Slaves.

    • 12

  2. No meu casoPURGE BINARY simplesmente não estava deletando nada.

    Eu tinha minha partição com 100% de uso (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 foi necessário neste servidor e eu tinha esquecido de removê-lo), e então reiniciei o mysql (isso foi necessário porque havia consultas enfileiradas que estavam impedindo PURGE BINARYde serem executadas).

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

    Esta instrução não tem efeito se o servidor não foi iniciado com a opção --log-bin para habilitar o log binário.

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

    • 10

  3. Eu não tenho certeza se isso é o que aconteceu com você, mas no meu caso o MySQL parou de "ciclagem" de logs e o arquivo mysql-bin.index ficou "corrompido" com entradas inválidas do arquivo binlog.

    Especificamente, o arquivo de índice começou em mysql-bin.000001 e chegou a mysql-bin.000220, mas de alguma forma começou novamente a partir de 001. Quando comparei isso com os arquivos no meu servidor, pude ver que tinha arquivos de 001 a 022.

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

    No final, parei o MySQL e editei manualmente o arquivo de índice até que ele 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.

    • 8

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

    • 6

  5. 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 = 10em my.cnf. Por padrão expire_logs_days é 0 = nunca exclua logs.

    ( fonte )

    • 1

relate perguntas