Manual de Referência do MySQL :: A.4.1 O Que Fazer Se o MySQL Continua Falhando

• Alguém/algo finalize o mysqld ou a máquina no meio de uma atualização.

• Você encontrou um bug no mysqld que faça com que ele finalize no meio de uma atualização.

• Alguém está manipulando os arquivos de dados/índices de fora do mysqld sem o bloqueio de tabela apropriado.

• Se você estiver executando muitos servidores mysqld no mesmo dado em um sistema que não suporta bons bloqueios de sistema de arquivos (normalmente tartando o daemon lockd) ou se você está executando multiplos servidores com --skip-external-locking

• Você tem um arquivo de dados/índices que contem muitos dados errados que deixam o mysqld confuso.

• Você encontrou um bug no código de armazenamento do dado. Isto não é desejável mas é possível. Neste caso você ode tentar alterar o tipo de arquivo para outro mecanismo de armazenamento usando ALTER TABLE em uma cópia corrigida da tabela!

Finalize o daemon mysqld com mysqladmin shutdown, execute myisamchk --silent --force */*.MYI em todas as tabelas e reinicie o daemon mysqld. Isto irá assegurar que você está executando de um estado ``limpo''. See Capítulo 4, Administração do Bancos de Dados MySQL.

• Use mysqld --log e tente determinar a partir da informação no log se alguma consulta específica finalizou o servidor. Aproximadamente 95% de todos os erros são relacionados com um consulta em particular! Normalmente ela é uma das últimas consultas no arquivo de log antes do MySQL reiniciar See Secção 4.10.2, “O Log de Consultas”. Se você puder finalizar o MySQL repetidamente com uma das consultas, mesmo quando você tiver verificado todas as tabelas logo antes de realizá-la, então você estará apto a localizar o bug e deve fazer um relatório de bug para isto! See Secção 1.7.1.3, “Como relatar erros ou problemas”.

• Tente fazer um caso de teste que possamos utilizar para reproduzir o problema. See Secção E.1.6, “Fazendo um Caso de Teste Se Ocorre um Corrompimento de Tabela”.

• Tente executar o teste incluso mysql-test e o benchmark do MySQL. See Secção 14.1.2, “Pacotes de Teste do MySQL”. Eles devem testar o MySQL bem. Você também pode adicionar ao benchmark um código que simule a sua aplicação! O benchmark pode ser encontrado no diretório bench na distribuição fonte ou, em uma distribuição binária, no diretório sql-bench sob o diretório de instalação do seu MySQL.

• Experimente fork_test.pl e fork2_test.pl.

• Se você configurar o MySQL para depuração, será muito mais fácil para obter informações sobre possíveis erros se alguma coisa der errado. Reconfigure o MySQL com a opção --with-debug ou --with-debug=full no configure e então recompile-o. See Secção E.1, “Depurando um Servidor MySQL”.

• Configurar o MySQL para depuração faz com que um alocador de memória seja incluído para que se possa encontrar alguns erros. Ele também fornece muita informação sobre o que está acontecendo.

• Você aplicou todas as últimas correções para o seu sistema operacional?

• Use a opção --skip-external-locking com o mysqld. Em alguns sistemas, o gerenciador de bloqueios lockd não funciona de forma apropriada; a opção --skip-external-locking faz com que mysqld não utilize bloqueio externo. (Isto significa que você não pode executar 2 servidores mysqld sobre o memo dado e que você deve ser cuidadoso ao utilizar myisamchk, mas pode ser instrutivo tentar a opção como teste).

• Você tentou mysqladmin -u root processlist quando o mysqld parecia estar rodando mas não respondia? Algumas vezes o mysqld não está <<comatose>> mesmo quando você acha que não. O problema pode ser que todas as conexões estão em uso, o pode haver algum problema interno de bloqueio. mysqladmin processlist normalmente estará apto a fazer uma conexão mesmo nestes casos e pode fornecer informação útil sobre o número conexões atuais e os seus estados.

• Execute o comando mysqladmin -i 5 status ou mysqladmin -i 5 -r status ou em uma janela separada para produzir estatísticas enquanto você executa outras consultas.

• Experimente o seguinte:

  1. Inicie o mysqld a partir do gdb (ou em outro depurador). See Secção E.1.3, “Depurando o mysqld no gdb”.

  2. Execute o seu script de testes.

  3. Imprima o <<backtrace>> e as varáveis locais nos 3 níveis mais baixos. No gdb você pode fazê-lo com o seguinte comando quando o mysqld falhar dentro do gdb:

     backtrace
     info local
     up
     info local
     up
     info local
     

     Com gdb você também pode examinar quais threads existem com info threads e troca para uma thread específica com thread #, onde # é a ID da thread.

• Tente simular a sua aplicação com um script Perl para forçar o MySQL a falhar o mudar o seu comportamento.

• Envie um relatório de bug normal. See Secção 1.7.1.3, “Como relatar erros ou problemas”. Seja mais detalhista que o normal. Como o MySQL funciona para muitas pessoas, pode ser que as falhas resultem de algo que exista apenas em seu computador (por exemplo, um erro que é relacionado a suas bibliotecas de sistemas em particular).

• Se você tiver um problema em tabelas com registros do tamanho dinâmico e você não está usando colunas BLOB/TEXT (mas apenas colunas VARCHAR, você pode tentar alterar todas as colunas VARCHAR para CHAR com ALTER TABLE. Isto forçara o MySQL a usar linhas de tamanho fixo. Linhas de tamanho fixo utilizam um pouco mais de espaço extra, mas são muito mais tolerante a corrompimento.

  O código de registro dinâmico atual foi usado pela MySQL AB por pelo menos 3 anos em qualquer problema, mas por natureza os registro de tamanho dinâmico são mais propensos a erros, assim pode ser uma boa idéia tentar o exposto acima para ver se ajuda.