Skip navigation links
A.4.2 Como Recuperar uma Senha de Root Esquecida »
Section Navigation      [Toggle]

A.4.1. O Que Fazer Se o MySQL Continua Falhando

Todas as versões do MySQL são testadas em muitas plataformas antes de serem distribuídas. Isto não significa que não existe nenhum erro no MySQL, mas significa que se houver erros, eles são poucos e podem ser difíceis de encontrar. Se você tiver u problema, sempre ajudará se você tentar encontrar exatamente o que falhou em seu sistema e assim você terá uma chance muito maior de tê-lo corrigido rapidamente.

Primeiro, você deve tentar descobrir o problema é que o daemon do mysqld morre ou se o seu problema é relativo ao seu cliente. Você pode verificar o quanto tempo o seu servidor mysqld está em execução utilizando o mysqladmin version. Se o mysqld morrer, você pode encontrar a causa disto no arquivo mysql-data-directory/`nome_maquina`.err. See Secção 4.10.1, “O Log de Erros”.

Em alguns sistemas você pode encontrar neste arquivo um stack trace de onde o mysqld finalizou e assim você pode resolver com resolve_back_stack. See Secção E.1.4, “Usando Stack Trace”. Note qte os valores da variável escrita no arquivo .err não podem sempre estar 100% corretas.

Muitas falhas do MySQL são causadas por arquivos de índices/dados corrompidos. O MySQL atualizará os dados em disco, com a chamada de sistema write(), depois de todas as intruções SQL e antes do ser notificado sobre o resultado. (Isto não é verdade se você estiver executando com delay_key_write, caso no qual apenas o dado é escrito.) Insto significa que o dado é salvo mesmo se o mysqld falhar, já que o SO se certificará de que o dado não descarregado esta escrito em disco. Você pode forçar o MySQL a sincronizar tudo para o disco depois de todo comando SQL inicando o mysqld com --flush.

O exposto acimo significa que normalmente você não deve ter tabelas corrompidas a menos que:

  • 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!

Por ser muito difícil saber o motivo das falhas, tente primeiro verificar se o que está funcionando para outros está falhando com você. Por favor, tente o seguinte:

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.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.