Por que o MySQL está escrevendo centenas de arquivos de log binários de 125 bytes?

Question

Meu MySQL Master (sem escravos conectados agora) grava um arquivo de 125 bytes a cada minuto ou mais:

-rw-rw---- 1 mysql mysql        125 2012-12-28 16:46 snapshot-mysql-v2-bin.004876
-rw-rw---- 1 mysql mysql        125 2012-12-28 16:45 snapshot-mysql-v2-bin.004875
-rw-rw---- 1 mysql mysql        125 2012-12-28 16:43 snapshot-mysql-v2-bin.004874
-rw-rw---- 1 mysql mysql        125 2012-12-28 16:41 snapshot-mysql-v2-bin.004873

ao gravar o conteúdo real do log binário em um arquivo com um número muito menor:

-rw-rw---- 1 mysql mysql  330755915 2012-12-28 16:48 snapshot-mysql-v2-bin.004472

(e quando o arquivo é preenchido, vai para o próximo arquivo).

Além disso, o MySQL não está escrevendo o nome do arquivo real com conteúdo (004472 acima) para o arquivo .index, então quando eu conecto um escravo, ele não pode replicar até eu editar o arquivo .index manualmente.

A versão do MySQL é 5.1.41-3ubuntu12.10-log.

Alguma idéia?

    

Answer 1

O problema parece ter sido que o arquivo / var / lib / mysql / ibdata1 foi bloqueado e não gravável pelo MySQL. Eu encontrei um monte de entradas para esse efeito no arquivo mysql.err, apesar do fato de que o servidor MySQL estava funcionando bem (e muitas linhas foram adicionadas às tabelas InnoDB).

Para consertar, eu tive que matar todas as instâncias do mysqld (o mysqladmin shutdown não foi o suficiente para obtê-las), e então eu corri:

cp -a ibdata1 ibdatanew1

e eu editei o my.cnf para apontar para o arquivo ibdatanew1. Eu iniciei o MySQL novamente, reiniciei o master, limpei os logs, e está tudo bem nas últimas 6 horas.

Ainda não estou claro como o arquivo ibdata1 que está sendo bloqueado teria permitido que o MySQL continuasse em execução, mas talvez o problema ibdata1 tenha surgido apenas com relação à gravação do log binário? (De nota, estou acostumado a ver problemas de ibdata1 no mysqld.log, não no log mysql.err).