Logs do banco de dados

Uma mensagem como "erro ao gravar" pode esconder situações diferentes: um dado duplicado, uma coluna desconhecida, uma espera por bloqueio ou uma perda de conexão. Os registros do acesso ao banco e do próprio servidor ajudam a separar o comando que falhou dos acontecimentos do serviço MySQL.

O registro de erros da aplicação

Muitas aplicações gravam, em um arquivo próprio, os comandos SQL que falharam e as mensagens de erro do acesso ao MySQL. O nome e o local desse arquivo variam com a instalação, em geral dentro da pasta do programa.

A leitura junta o comando, o código e a mensagem completa. O comando mostra a operação tentada e os nomes do banco, da tabela e da coluna, e o erro descreve a condição percebida pelo banco ou pela biblioteca de conexão, sem identificar sempre a causa. Os códigos mais comuns são estes:

• 1062, Duplicate entry: um valor repetido em uma chave única, de uma ou de várias colunas, e a mensagem informa a chave, mas não por que o valor se repetiu;
• 1146, Table doesn't exist: a tabela citada não foi encontrada no banco indicado, e o nome e o banco em uso são conferidos;
• 1054, Unknown column: uma coluna citada é desconhecida naquele contexto, por uma estrutura diferente da esperada depois de uma atualização, por um nome errado ou por uma referência errada no comando;
• 1205, Lock wait timeout exceeded: o prazo de espera por um bloqueio terminou, e, no InnoDB, outra transação pode estar segurando o recurso, sem que o código diga qual;
• 1213, Deadlock found: um ciclo de esperas por bloqueios, em que o InnoDB desfaz uma das transações para as outras continuarem;
• 1045, Access denied: o acesso foi recusado, e o usuário, a origem da conexão e os detalhes da autenticação são conferidos, porque o código não prova, sozinho, uma senha errada;
• 2006, MySQL server has gone away: o cliente perdeu a conexão com o servidor, e o reinício, os limites de espera e as dificuldades de comunicação são hipóteses que dependem do contexto;
• 2013, Lost connection to MySQL server during query: a conexão caiu durante uma consulta, e o resultado de uma gravação em andamento fica sem confirmação para o cliente.

Uma perda de conexão depois de uma tentativa de gravação deixa o resultado sem confirmação, e a situação da operação é conferida pelo procedimento do sistema antes de qualquer repetição.

O comando e a transação

Uma operação do sistema pode executar vários comandos dentro de uma transação. Para interpretar o efeito de um erro, a leitura confere o engine, os limites da transação, os COMMIT e os ROLLBACK registrados e o tratamento feito pelo programa. Uma linha de erro não informa o estado de todos os comandos anteriores.

No InnoDB, um deadlock desfaz a transação escolhida como vítima. Um tempo de espera esgotado desfaz, por padrão, só o comando que esperava, e a opção innodb_rollback_on_timeout pode estender esse efeito à transação inteira. Por isso, os erros 1205 e 1213 não recebem a mesma interpretação sobre o que ficou pendente, e a retomada segue o tratamento da aplicação, sem a repetição manual de uma gravação isolada.

Quando a conexão cai enquanto o cliente espera a confirmação de um COMMIT, o cliente pode ficar sem saber se a confirmação aconteceu. Uma consulta posterior verifica o documento ou a chave comercial e os efeitos relacionados, pelo procedimento do sistema, e uma linha parcial encontrada não basta para declarar a operação inteira concluída.

O log de erros do MySQL

O servidor MySQL registra a inicialização, o desligamento, a recuperação e algumas condições de erro e de aviso. Um comando mostra o destino configurado:

• SHOW VARIABLES LIKE 'log_error';: mostra o arquivo de destino do log de erros.

Nem toda instalação grava em um único arquivo, porque a versão, as opções de inicialização e os componentes de log influenciam o destino. Se o valor não aponta para um caminho utilizável, a configuração do serviço é conferida com quem administra o servidor.

O horário do log também depende da versão. No MySQL 5.1, as linhas trazem a hora local do servidor, sem o fuso, com a data em dois algarismos para o ano, o mês e o dia. A partir do MySQL 5.7, a variável log_timestamps define o horário das mensagens e tem o UTC como padrão, e, sem ajuste, o log fica três horas à frente do horário de Brasília.

As mensagens procuradas são as do mesmo período da falha: a recuperação depois de um encerramento inesperado, as tabelas marcadas como danificadas, com o aviso marked as crashed, típico do MyISAM, os erros do InnoDB e os avisos de conexões encerradas, como Aborted connection. A recuperação não prova uma queda de energia, uma conexão encerrada não prova um defeito de cabo, e a razão vem do cruzamento com os registros do Windows e do programa.

O log de consultas lentas e o log geral de comandos têm funções diferentes do log de erros e podem estar desligados. Ligá-los é uma decisão administrativa, porque eles acrescentam gravações, consomem disco e expõem os comandos.

As tabelas de log

Algumas integrações guardam as tentativas em tabelas, com a data, a situação e a mensagem. A leitura examina o histórico do identificador certo e a ordem dos registros, e, quando as datas empatam, outro campo de sequência mostra a ordem. O significado de cada linha também precisa ser conhecido, porque ela pode representar uma tentativa, uma mudança de situação ou um resultado.