XOOPS Brasil

 

Os Arquivos de Log do MySQL





O MySQL tem vários arquivos de log diferentes que podem ajudá-lo a descobrir o que está acontecendo dentro do mysqld:

Log fileDescription
O log de errosProblemas encontrados iniciando, executando ou parando o mysqld.
O log isamDocumenta todas alterações a tabelas ISAM. Usado somente para depuração do código isam.
O log de consultasConexões estabelecidas e consultas executadas.
O log de atualizaçõesDesatulizado: Armazena todas as instruções que alteram dados.
O log binárioArmazena todas as instruções que alteram qualquer coisa. Usada também para replicação.
O log para consultas lentasArmazena todas queries que levaram mais de long_query_time segundos para executar ou que não usaram índices.

Todos logs podem ser encontrados no diretório de dados do mysqld. Você pode forçar o mysqld a reabrir os arquivos de log (ou em alguns casos trocar para um novo log) executando FLUSH LOGS. Veja mais informações sobre isto na Seção 4.6.4, “Sintaxe de FLUSH.

4.10.1. O Log de Erros

A arquivo de log de erro contém informações indicando quando o mysqld foi iniciado e finalizado e também qualquer erro crítico encontrado na execução.

Se o mysqld finaliza inesperadamente e o mysqld_safe precisar reiniciar o mysqld, mysqld_safe gravará uma linha restarted mysqld neste arquivo. Este log também guarda um aviso se o mysqld notificar uma tabela que precisa ser automaticamente verificada ou reparada.

Em alguns sistemas operacionais, o log de erro irá conter registros de pilha de onde o mysqld finalizou. Isto pode ser usado para saber onde e como o mysqld morreu. Veja mais informações sobre isto na Seção E.1.4, “Usando Stack Trace”.

A partir do MySQL 4.0.10 você pode especificar onde o mysqld armazena o arquivo de log de erro com a opção --log-error[=filename]. Se nenhum nome de arquivo for dado, o mysqld usará mysql-data-dir/'maquina'.err no Unix e \mysql\data\mysql.err no Windows.i Se você executar flush logs o arquivo antigo terá o prefixo --old e o mysqld criará um novo arquivo de log vazio.

Em versões mais antigas do MySQL o tratamento do log de erro era feito pelo mysqld_safe o qual redirecionava o arquivo de erro para 'maquina'.err. Pode se alterar este nome de arquivo com a opção --err-log=nome_arq.

Se você não especificar --log-error ou se você utilizar a opção --console, o erro será escrito em stderr (o terminal).

No Windows a saída é sempre feita no arquivo .err se --console não for utilizado.

4.10.2. O Log de Consultas

Se você deseja saber o que acontece com mysqld, você deve iniciá-lo com a opção --log[=arquivo]. Isto irá documentar todas conexões e consultas no arquivo log (por padrão nomeado 'nome_máquina'.log). Este log pode ser muito útil quando você suspeitar de um erro em um cliente e deseja saber exatamente o que o mysqld acha que o cliente enviou.

Older versions of the mysql.server script (from MySQL 3.23.4 to 3.23.8) pass mysqld_safe a --log option (enable general query log). If you need better performance when you start using MySQL in a production environment, you can remove the --log option from mysql.server or change it to --log-bin. Veja mais informações sobre isto na Seção 4.10.4, “O Log Binário”.

Versões mais antigas do script mysql.server (MySQL 3.23.4 a 3.23.8) passam ao safe_mysql uma opção --log (habilita a log de consulta geral). Se você precisar melhorar a performance quando iniciar o uso do MySQL em um ambiente de produção, pode remover a opção --log do mysql.server ou alterá-lo para --log-bin. Veja mais informações sobre isto na Seção 4.10.4, “O Log Binário”.

As entradas neste log são escritas quando o mysqld recebe as questões. Pode estar diferente da ordem em que as instruções são executadas. Isto está em contraste com o log de atualizações e o log binário nos quais as consultas são escritas depois de serem executadas, mas que quaisquer travas sejam liberadas.

4.10.3. O Log de Atualizações

NOTA: O log de atualizações está obsoleto e foi substituído pelo log binário. Veja mais informações sobre isto na Seção 4.10.4, “O Log Binário”. O log binário pode fazer qualquer coisa que poderia ser feito com o log de atualizações, e mais. O log de atualização será removido no MySQL 5.0

Quando iniciado com a opção --log-update[=nome_arquivo], o mysqld grava um arquivo log contendo todos os comandos SQL que atualizam dados. Se nenhum arquivo for fornecido, o nome da máquina é usado. Se um nome de arquivo for fornecido, mas não possuir o caminho, o arquivo é gravado no diretório de dados. Se nome_arquivo não possuir uma extensão, o mysqld irá criar os arquivos com os nomes desta forma: nome_arquivo.###, onde ### é um número que é incrementado cada vez que mysqladmin refresh, mysqladmin flush-logs ou a instrução FLUSH LOGS forem executados ou o servidor for reiniciado.

NOTA: Para o esquema acima funcionar, você não pode criar seus próprios arquivos com o mesmo nome que os do log de atualização + algumas extensões que podem ser tratadas como números, no diretório usado pelo log de atualização!

Se forem utilizadas as opções --log ou -l, o mysqld escreve um log geral com o nome de arquivo nome_máquina.log, e o reinicio e a recarga não geram um novo arquivo de log (embora ele seja fechado e reaberto). Neste caso você pode copiá-lo (no Unix) usando:

mv nome_máquina.log nome_máquina-antigo.log
mysqladmin flush-logs
cp nome_máquina-antigo.log para-diretório-backup
rm nome_máquina-antigo.log

O log de atualização é inteligente pois registra somente instruções que realmente alteram dados. Portanto, um UPDATE ou um DELETE com uma cláusula WHERE que não encontre nenhum registro não é escrito no log. Ele salta até instruções UPDATE que atribui a uma coluna o mesmo valor que ela possuia.

O registro da atualização é feito imediatamente após uma consulta estar completa mas antes que as bloqueios sejam liberados ou que algum commit seja feito. Isto garante que o log seja escrito na ordem de execução.

Se você desejar atualizar um banco de dados a partir de arquivos de logs de atualização, você pode fazer o seguinte (assumindo que seus logs de atualização estejam nomeados na forma nome_arquivo.###):

shell> ls -1 -t -r nome_arquivo.[0-9]* | xargs cat | mysql

ls é utilizado para obter todos os arquivos de log na ordem correta.

Isto pode ser útil se você tiver que recorrer a arquivos de backup depois de uma falha e desejar refazer as atualizações que ocorreram entre a hora do backup e a falha.

4.10.4. O Log Binário

O log binário deve substituiu o log de atualizações. O log de atualizações será removido do MySQL 5.0. O log binário contém toda informação que está disponível no log de atualizações em um formato mais eficiente e de maneira transacionalmente segura.

O log binário, como o antigo log de atualização, apenas registra instruções que realmente atualizam os dados. Assim um UPDATE ou um DELETE com um WHERE que não encontra nenhum registro não é gravado no log. Ele ignora mesmo instruções UPDATE que definam a uma coluna um valor que ela já tenha.

O propósito principal do log binário é poder atualizar o banco de dados durante uma operação de restauração de forma mais completa possível, já que o log binário conteria todas as atualizações feitas depois que um backup foi realizado.

O log binário é também usado para replicar um mysqld slave a partir de um master. Veja mais informações sobre isto na Seção 4.11, “Replicação no MySQL”.

O log binário também contém informação sobre o tempo que cada consulta leva para atualizar o banco de dados. Ele não contém consultas que não modificam dados. Se você quiser registrar todas as consultas (por exemplo, para encontrar um consulta com problema) você deve usar o log geral de consultas. Veja mais informações sobre isto na Seção 4.10.2, “O Log de Consultas”.

Quando iniciado com a opção --log-bin[=nome_arquivo], o mysqld escreve um arquivo de log contendo todos comandos SQL que atualizam dados. Se nenhum arquivo for fornecido, ele aponta para o nome da máquina seguido de -bin. Se for fornecido o nome do arquivo, mas ele não tiver o caminho, o arquivo é escrito no diretório de dados.

Se você fornecer uma extensão à --log-bin=nome_arquivo.extensão, a extensão será removida sem aviso.

O mysqld irá acrescentar uma extensão ao nome de arquivo do log binário que é um número que é incrementado cada vez que mysqladmin refresh, mysqladmin flush-logs, a instrução FLUSH LOGS forem executados ou o servidor for reiniciado. Um novo log binário também será automaticamente criado quando o tamanho do log atual alcançar max_binlog_size. Nota se você estiver usando transações: uma transação é escrita em um bloco no arquivo de log binário, já que ele nunca é separado entre diversos logs binários. Desta forma, se você tiver grnades transações, você pode ter logs binários maiores que max_binlog_size.

Você pode deletar todos os arquivos de log binário com o comando RESET MASTER (see Seção 4.6.5, “Sintaxe de RESET), ou apenas alguns deles com PURGE MASTER LOGS (see Seção 4.11.7, “Instruções SQL para Controle do Servidor Master”).

Você pode utilizar as seguintes opções ao mysqld para afetar o que é documentado pelo log binário (tenha certeza de ler as notas que seguem esta tabela):

OpçãoDescrição
binlog-do-db=nome_banco_dadosDiz ao master que ele deve registrar atualizações no log binário se o banco de dado atual (ex.: aquele selecionado por USE) é 'nome_banco_dados'. Todos os outros bancos de dados que não forem explicitamente mencionados são ignorados. Note que se você utilizá-lo você deve se assegurar que você só faz atualizações no banco de dados atual. (Exemplo: binlog-do-db=algum_bancodados) Exemplo do que não funciona como você poderia esperar: se o servidor é iniciado com binlog-do-db=sales, e você fizer USE prices; UPDATE sales.january SET amount=amount+1000;, esta consulta não será gravada no log binário.
binlog-ignore-db=nome_banco_dadosDiz ao master que atualizações onde o banco de dados atual (ex.: aquele selecionado com USE) é 'nome_banco_dados' não deve ser gravado no log binário. Note que se você usar esta opção você deve ter certeza que você só faz atualizações no banco de dados atual. (Exemplo: binlog-ignore-db=algum_banco_dados) Exemplo do que não funciona como você poderia esperar: se o servidor é iniciado com binlog-do-db=sales, e você fizer USE prices; UPDATE sales.january SET amount=amount+1000;, esta consulta será gravada no log binário.

As regras estão avaliadas na seguinte ordem, para decidir se a consulta deve ser escrita no log binário ou não:

  1. Existem as regras binlog-do-db ou binlog-ignore-db?

    • Não: grave a consulta no log binário e saia.

    • Sim: Vá para o passo abaixo.

  2. Então existe algumas regras (binlog-do-db ou binlog-ignore-db ou ambos). Existe um banco de dados atual (algum banco de dados foi selecionado com USE?)?

    • Não: NÃO grave a consulta e saia.

    • Sim: vá para o passo abaixo.

  3. Existe um banco de dados. Existe alguma regra binlog-do-db?

    • Sim: O banco de dados atual se encaixa em qualquer uma das regras binlog-do-db?

      • Sim: grave a consulta e saia.

      • Não: NÃO grave a consulta e saia.

    • Não: Vá para o passo abaixo.

  4. Existem algumas regras binlog-ignore-db. O banco de dados atual se encaixa em qualquer uma das regras binlog-ignore-db?

    • Sim: não grave a consulta e saia.

    • Não: grave a consulta e saia.

Então, por exemplo, um slave em execução com apenas binlog-do-db=sales não gravará no log binário qualquer consulta em que o banco de dados atual é diferente de sales (em outras palavras, binlog-do-db pode, significar algumas vezes, ``ignore outros bancos de dados'').

Para saber quais arquivos binários foram usados, o mysqld irá criar também um arquivo de índice para o log binário que contém o nome de todos os arquivos de log binário usados. Por padrão este arquivo tem o mesmo nome que o arquivo de log binário, com a extensão '.index'. Você pode alterar o nome do arquivo de índice do log binário com a opção --log-bin-index=[nome_arquivo]. Você não deve eduitar este arquivo manualmente enquanto o mysqld estiver em execução; fazer isto confundiria o mysqld.

Se estiver sendo usado replicação, os arquivos de log binário antigos não devem ser apagados até ter certeza que nenhum slave irá mais precisar deles. Uma forma de fazer isto é o utilizar mysqladmin flush-logs uma vez por dia e então remover qualquer log com mais de 3 dias. Você pode removê-los manualmente, ou de preferência usando PURGE MASTER LOGS (see Seção 4.11.7, “Instruções SQL para Controle do Servidor Master”) o qual atualizará de forma segura o arquivo de índice do log binário para você (e que pode ter um argumento de data desde o MySQL 4.1)

Uma conexão com o privilégio SUPER pode desabilitar o registro no log binário de suas consultas usando SET SQL_LOG_BIN=0. Veja mais informações sobre isto na Seção 4.11.7, “Instruções SQL para Controle do Servidor Master”.

Você pode examinar o arquivo de log binário com o utilitário mysqlbinlog. Por exemplo, você pode atualizar um servidor MySQL a partir de um log binário como mostrado a seguir:

mysqlbinlog arquivo-log | mysql -h nome_servidor

Veja Seção 4.9.5, “mysqlbinlog, Executando as Consultas a Partir de um Log Binário” para mais informações sobre o utilitário mysqlbinlog e como utilizá-lo.

mysqlbinlog --help irá lhe fornecer mais informações de como usar este programa!

Se você estiver utilizando BEGIN [WORK] ou SET AUTOCOMMIT=0, você deve utilizar o log binário do MySQL para backups no lugar do antigo log de atualização.

O Log binário é feito imedatamente depois que uma consulta terminar mas antes que os bloqueios sejam liberados ou algum commit seja feito. Isto garante que o log seja feito na ordem de execução.

Atualizações em tabelas não transacionais são armazenadas o log binário imediatamentedepois da execução. Para tabelas tranascionais como BDB ou InnoDB, Todas atualizações (UPDATE, DELETE ou INSERT) que alteram uma tabela transacional são armazenadas no cache até um COMMIT. Quaisquer atualizações a uma tabela não transacional são armazenadas no log binário de uma vez. Todas as threads irão, no início, alocar um buffer de binlog_cache_size para registrar consultas. Se uma conaulta é maior que o registro, a thread irá criar um arquivo temporário para lidar com a mesma. O arquivo temporário será apagado quando a thread terminar.

O max_binlog_cache_size (padrão 4G) pode ser usado para restringir o tamanho total usado para armazenar uma consulta multi-transacional. Se uma transação é maior que isto ela falhará e fará um roll back.

Se você estiver utilizando o log de atualização ou o binário, inserções concorrentes não funcionarão juntas com CREATE ... INSERT e INSERT ... SELECT. Isto é para garantir que você possa recriar uma cópia exata de suas tabelas aplicando o log em um backup.

4.10.5. O Log para Consultas Lentas

Quando iniciado com a opção --log-slow-queries[=file_name] o mysqld escreve em um arquivo log contendo todos os comandos SQL que levam mais de long_query_time segundos para executar. O tempo para obter os bloqueios de tabelas iniciais não são contados como tempo de execução.

O log de consultas lentas é gerado depois que uma query é executada e depois de todas as bloqueios serem liberados. Ela pode estar em ordem diferente da que as instruções foram executadas.

Se nenhum nome de arquivo for fornecido, o padrão é o nome da máquina com o sufixo -slow.log. Se um nome de arquivo for especificado, mas não conter o caminho, o arquivo é gravado no diretório de dados.

O log para queries lentas pode ser usado para encontrar queries que levam muito tempo para executar e que devem ser candidatas a otimização. Com um log muito grande, isto pode ser uma tarefa difícil. Você pode utilizar o log de consultas lentas através do comando mysqldumpslow para obter um resumo das consultas que aparecem no log.

Se a opção --log-long-format estiver sendo usada, então as consultas que não estiverem utilizando índices serão escritas. Veja mais informações sobre isto na Seção 4.1.1, “Opções de Linha de Comando do mysqld.

4.10.6. Manutenção do Log de Arquivo

O MySQL tem vários arquivos de log que possibilitam ver o que está ocorrendo com mais facilidade. Veja mais informações sobre isto na Seção 4.10, “Os Arquivos de Log do MySQL”. Porém de tempos em tempos deve ser feita uma limpeza nos arquivos de logs do MySQL para que eles não ocupem muito do espaço do disco.

Ao utilizar o MySQL com arquivos log, você necessitará de tempos em tempos remover antigos arquivos de log e dizer ao MySQL para logar com novos arquivos. Veja mais informações sobre isto na Seção 4.5.1, “Backups dos Bancos de Dados”.

Em uma instalação Linux RedHat), você pode usar o script mysql-log-rotate para isto. Se você instalou o MySQL de uma distribuição RPM, o script deve ter sido instalado automaticamente. Perceba que você deve ter cuidado com este script se você estiver utilizando o log binário para replicação!

Em outros sistemas você deve instalar um pequeno script que será executado pelo cron para lidar com os arquivos de log.

Você pode forçar o MySQL a iniciar utilizando novos arquivos de log usando mysqladmin flush-logs ou utlizando o comando SQL FLUSH LOGS. Se você usa o MySQL Versão 3.21 deve utilizar o comando mysqladmin refresh.

O comando acima faz o seguinte:

  • Se o log padrão (--log) ou log de consultas lentas (--log-slow-queries) forem utilizados, fecha e reabre o arquivo de log. (mysql.log e `hostname`-slow.log como padrão).

  • Se o log de atualização (--log-update) é usado, fecha o log de atualização e abre um novo arquivo log com uma sequência numérica mais alta.

Se você só estiver utilizando o log de atualização, você tem apenas que atualizar os logs e então mover os arquivos de log antigos para um backup. Se você estiver utilizando o log normal, você pode fazer algo assim:

shell> cd diretório-dados-mysql
shell> mv mysql.log mysql.old
shell> mysqladmin flush-logs

e então fazer um backup e remover o mysql.old.