Resenha:
Minha alegria é chegar na empresa e descobrir que um servidor não está funcionando, meu cardiologista já disse que literalmente não conseguiria mais viver sem mim e agradece!
Dissertação:
O MySQL é um dos mais confiáveis SGDBs que já trabalhei, não que tenha tido muitas experiências com outros, mas até o momento ele não me deixou na mão, trabalho com bancos de dados com um certo tamanho (mais de 4GB e 20 bilhões de linhas em uma única tabela) e ao menos sempre que ele tem um curto circuito eu tenho uma maneira rápida de corrigir os problemas e quando o problema é muito complexo é muito fácil encontrar discussões sobre o assunto na internet. Vou contar uma situação que tive de crash em uma destas grandes tabelas, os crashes em MySQL geralmente ocorrem por falta de memória que é mal dimensionado pelo administrador de sistemas, neste caso eu, o sistema está configurado para poder consumir uma quantidade x de memória e nesta situação ele deveria estar configurado para consumir X-200MB de memória, quando ele tentou consumir (X-200MB)+1MB ele não conseguiu e travou, ficou emitindo mensagens que estava sem recursos para continuar, depois de alguns avisos ele simplesmente congelou e gerou uma falha no arquivo de indexação e outra falha no arquivo de dados que estavam des-sincronizados.
Após reinicializar o mysql a primeira coisa que fiz foi tentar alguma operação para verificar se estava tudo ok e o sistema informou ...
error : Table '<>' is marked as crashed and last (automatic?) repair failed
... Tentei um simples comando para otimizar as tabelas (comando optmize tables) direto no shell do sgdb (software mysql client), mas ele continuava falando que estava com a tabela quebrada e não poderia efetuar o comando, entrei em desespero! Minha primeira ação foi dar uma googleada e abrir uns 10 sites, todos ao mesmo tempo, dar uma rápida olhada no que era interessante, fechar as besteiras e começas a estudar o que era me parecia útil. Encontrei um comentário, seria o princípio da salvação de minha lavoura. O thread no forum discernia sobre um software, o vbulletin, e um processo para resolver craches do banco do software.
Depois de estudar bem as dicas repassadas no thread e de navegar um pouco mais, encontrar os diversos tipos de erros que podem vir a ocorrer com a base de dados e compreender o funcionamento do mysqlcheck resolvi então ler por completo a página de manual do comando. Finalmente cheguei na seguinte seqüência de comandos ...
# 01) desliguei o apache prevenindo novas conexões
httpd stop
# 02) Esperei até que todos os processos fossem finalizados
mysqladmin proc stat -v -u <> -p<>
# 03) efetuei o flush de todas as informações
mysqladmin flush-tables > -p<>
# 04) Rodei o comando para otimizar as tabelas
mysqlcheck -o --all-databases --user=<> --password=<>
obs) Este é o mesmo comando que o “myisamchk -o -v */*.MYI” porem o myisamcheck deve ser executado no diretório de arquivos do banco de dados e o SGDB não pode estar ligado.
# 05) este comando corrige os problemas.
mysqlcheck -F -r -v --all-databases --user=<> --password=<>
obs) Este é o mesmo comando que o “myisamchk -f -r -v *.MYI” porem o myisamcheck deve ser executado no diretório de arquivos do banco de dados e o SGDB não pode estar ligado.
# 06) restartei o apache
httpd start
As explicações obvias do porquê parei o apache e o porquê resolvi descarregar os buffers é básica, pergunte ao amigo ao lado. Mas porquê optei por otimizar as tabelas antes de corrigi-las? A opção “-F” faz com que o mysqlchek proceda as correções apenas nas tabelas que não tenham sido marcadas como “fechadas apropriadamente”, não estudei o suficiente, entretanto acredito que desta forma o sistema irá marcar as tabelas menos utilizadas do sistema como estáveis e ao passar o segundo comando de correção este só atuará sobre tabelas problemáticas, dando então maior velocidade ao corrigir as tabelas. A segunda execução do mysqlcheck já temos a opção -v, para apresentar informações do que está acontecendo, evitando assim de entrarmos em desespero caso o relógio “aperte”, e por fim a opção “-r”, que ao que compreendi do manual simplesmente resolveria todos os problemas possíveis de ocorrerem com a base de dados, se a opção “-r” não solucionar o seu problema, larga tudo e dá uma passada na igreja para se benzer pois vai precisar de reza braba.
Após reinicializar o mysql a primeira coisa que fiz foi tentar alguma operação para verificar se estava tudo ok e o sistema informou ...
error : Table '<
... Tentei um simples comando para otimizar as tabelas (comando optmize tables) direto no shell do sgdb (software mysql client), mas ele continuava falando que estava com a tabela quebrada e não poderia efetuar o comando, entrei em desespero! Minha primeira ação foi dar uma googleada e abrir uns 10 sites, todos ao mesmo tempo, dar uma rápida olhada no que era interessante, fechar as besteiras e começas a estudar o que era me parecia útil. Encontrei um comentário, seria o princípio da salvação de minha lavoura. O thread no forum discernia sobre um software, o vbulletin, e um processo para resolver craches do banco do software.
Depois de estudar bem as dicas repassadas no thread e de navegar um pouco mais, encontrar os diversos tipos de erros que podem vir a ocorrer com a base de dados e compreender o funcionamento do mysqlcheck resolvi então ler por completo a página de manual do comando. Finalmente cheguei na seguinte seqüência de comandos ...
# 01) desliguei o apache prevenindo novas conexões
httpd stop
# 02) Esperei até que todos os processos fossem finalizados
mysqladmin proc stat -v
mysqladmin flush-tables
# 04) Rodei o comando para otimizar as tabelas
mysqlcheck -o --all-databases --user=<
obs) Este é o mesmo comando que o “myisamchk -o -v */*.MYI” porem o myisamcheck deve ser executado no diretório de arquivos do banco de dados e o SGDB não pode estar ligado.
# 05) este comando corrige os problemas.
mysqlcheck -F -r -v --all-databases --user=<
obs) Este é o mesmo comando que o “myisamchk -f -r -v *.MYI” porem o myisamcheck deve ser executado no diretório de arquivos do banco de dados e o SGDB não pode estar ligado.
# 06) restartei o apache
httpd start
As explicações obvias do porquê parei o apache e o porquê resolvi descarregar os buffers é básica, pergunte ao amigo ao lado. Mas porquê optei por otimizar as tabelas antes de corrigi-las? A opção “-F” faz com que o mysqlchek proceda as correções apenas nas tabelas que não tenham sido marcadas como “fechadas apropriadamente”, não estudei o suficiente, entretanto acredito que desta forma o sistema irá marcar as tabelas menos utilizadas do sistema como estáveis e ao passar o segundo comando de correção este só atuará sobre tabelas problemáticas, dando então maior velocidade ao corrigir as tabelas. A segunda execução do mysqlcheck já temos a opção -v, para apresentar informações do que está acontecendo, evitando assim de entrarmos em desespero caso o relógio “aperte”, e por fim a opção “-r”, que ao que compreendi do manual simplesmente resolveria todos os problemas possíveis de ocorrerem com a base de dados, se a opção “-r” não solucionar o seu problema, larga tudo e dá uma passada na igreja para se benzer pois vai precisar de reza braba.
