Os logs binários do Mysql não estão girando, particionam sem espaço, as consultas de administrador relacionadas à replicação são travadas

Question

Eu tenho uma caixa onde a partição raiz está cheia.

A explicação mais imediata é que os logs binários do mysql não estão girando. Apesar de expire_log_days estar definido como 10, existem logs com mais de 10 dias. show master status , show slave status e purge binary logs todos são interrompidos indefinidamente.

    

Answer 1

Eu tentaria algumas coisas, mas certifique-se de que estar cheio é o seu problema. Normalmente o Mysql armazena dados em / var / lib / mysql e não usa / para muito além de / tmp.

Primeiro, tente limpar algum espaço. Excluir logs antigos de / var / log / ou bater o código src que você baixou e nunca usou. Se você puder obter / descer para menos de 100%, o Mysql poderá retornar a um estado em que não está encravado.

Supondo que você tenha limpado algum espaço, tente limpar os logs. Eu tentaria PURGAR REGISTOS BINÁRIOS ANTES DE DATE_SUB (NOW (), INTERVAL 3 DAY); da linha de comando do Mysql. Se ele ainda parar depois de dez minutos, você provavelmente precisará desligar o Mysql se puder ou matá-lo se não puder.

Normalmente, nunca é uma boa ideia excluir registros manualmente, mas, nesse caso, pode ser sua única opção. Exclua o log mais antigo e tente reiniciar o Mysql. Provavelmente terá que fazer algumas verificações de tabela. Fique de olho no log de erro do mysql até que ele esteja funcionando corretamente. Em seguida, tente limpar os registros novamente.

Assim que estiver em funcionamento, certifique-se de que expire_logs_days esteja realmente configurado, verificando as variáveis de show; em Mysql. Você também pode querer definir max_binlog_size = 100M se o seu sistema de arquivos for pequeno. Normalmente, o Mysql roda logs em 1G, o que pode não ser suficiente. O Mysql só gira os logs quando o log atual atinge o tamanho máximo.

    

Answer 2

Isso depende inteiramente da versão do MySQL que você está executando

O problema está no mapa de memória de todos os logs binários.

Quando o mysqld inicia, ele lê o índice de logs binários do mysql na memória.

Esse mapa de memória é sensível à presença de logs binários no disco.

Se você fizer comandos como:
1. PURGAR REGISTROS BINÁRIOS PARA '< nome de arquivo de log binário > ';
2. PURGAR REGISTOS BINÁRIOS ANTES '< data e hora > ';
3. RESET MASTER;

O mysqld usará o mapa de memória em vez do arquivo de índice de log binário.

Se o mapa de memória não corresponder exatamente aos arquivos de logs binários no disco (ou seja, não em sych), a rotação de log com expire_logs_days falhará.

Você não pode simplesmente editar o arquivo de índice do log binário do mysql, porque quando você emite um shutdown para o mysqld, o mapa da memória sobrescreverá o arquivo de índice do log binário.

O problema geralmente acontece quando alguém exclui os logs binários no sistema operacional, em vez de usar um dos três (3) Comandos MySQL mencionados anteriormente. O mysqld não vai apenas pegar o súbito desaparecimento de logs binários.

A única correção imediata possível é excluir todos os logs binários, excluir o arquivo de índice do log binário e iniciar o backup do mysql, ou você pode fazer o seguinte:

1. desligamento do mysql
2. excluir logs binários que você não deseja
3. edite o arquivo de índice de log binário (remova logs binários que não existem no arquivo)
4. iniciar o mysqld

Para ficar atento ao desaparecimento dos logs binários a partir de então, execute SHOW BINARY LOGS; Se alguma das entradas de registros binários retornar com tamanho de arquivo 0, o mapa de memória dos logs binários está fora de sych. O curso de ação, então, é fazer o seguinte:

1. desligamento do mysql
2. edite o arquivo de índice de log binário (remova logs binários que não existem no arquivo)
3. iniciar o mysqld

Answer 3

Meu conselho é que, uma vez que você o salve, coloque / var / lib / mysql e / var / log / mysql em seus próprios volumes LVM.