Resenha:
Se “quando o banco para o país está em crise”, podemos dizer em TI que “quando o banco para o administrador entra em crise”! Descrevo minha última experiência com crash em uma base de dados MySQL. Se você é um administrador de banco de dados reze para não ler este artigo! ....
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 2GB 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.
A primeira coisa que fiz foi um simples comando para otimizar as tabelas, como o comando optmize tables direto no shell do sgdb, mas ele continuava falando ...
error : Table '<>' is marked as crashed and last (automatic?) repair failed
... entrei em desespero! Minha primeira ação foi dar uma googleada, 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 me parecia útil até encontrar um comentário que poderia ser o princípio da salvação de minha lavoura. Fui um thread de um forum que discernia sobre um software, o vbulletin e um processo para resolver craches do banco.
Depois de estudar bem as dicas repassadas no thread, de navegar um pouco mais para 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 ...
# desliguei o apache prevenindo novas conexões
httpd stop
# Esperei até que todos os processos fossem finalizados
mysqladmin proc stat -v -u usuario -psenha
# efetuei o flush de todas as informações
mysqladmin flush-tables -u usuario -psenha
# Rodei o comando para otimizar as tabelas
mysqlcheck -o --all-databases –user=usuario –password=senha
# este comando corrige os problemas.
mysqlcheck -F -r -v --all-databases –user=usuario –password=senha
# restartei o apache
httpd start
Vamos as explicações
As explicações obvias do porquê parei o apache e o porquê resolvi descarregar os buffers é básica, pergunte ao amigo/superior ao lado. Mas porquê optei por otimizar as tabelas antes de corrigi-las? Simples, 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 simplesmente resolveria todos os problemas possíveis de ocorrerem com a base de dados, segundo o que compreendi do manual, 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.
Ainda não tive tempo, porem vou colocar as três últimos comandos para rodar no cron todo sábado à noite, na espera de que tal processo diminua a possibilidade de ocorrência de um bug maior.
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!
A primeira coisa que fiz foi um simples comando para otimizar as tabelas, como o comando optmize tables direto no shell do sgdb, mas ele continuava falando ...
error : Table '<
... entrei em desespero! Minha primeira ação foi dar uma googleada, 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 me parecia útil até encontrar um comentário que poderia ser o princípio da salvação de minha lavoura. Fui um thread de um forum que discernia sobre um software, o vbulletin e um processo para resolver craches do banco.
Depois de estudar bem as dicas repassadas no thread, de navegar um pouco mais para 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 ...
# desliguei o apache prevenindo novas conexões
httpd stop
# Esperei até que todos os processos fossem finalizados
mysqladmin proc stat -v -u usuario -psenha
# efetuei o flush de todas as informações
mysqladmin flush-tables -u usuario -psenha
# Rodei o comando para otimizar as tabelas
mysqlcheck -o --all-databases –user=usuario –password=senha
# este comando corrige os problemas.
mysqlcheck -F -r -v --all-databases –user=usuario –password=senha
# restartei o apache
httpd start
Vamos as explicações
As explicações obvias do porquê parei o apache e o porquê resolvi descarregar os buffers é básica, pergunte ao amigo/superior ao lado. Mas porquê optei por otimizar as tabelas antes de corrigi-las? Simples, 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 simplesmente resolveria todos os problemas possíveis de ocorrerem com a base de dados, segundo o que compreendi do manual, 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.
Ainda não tive tempo, porem vou colocar as três últimos comandos para rodar no cron todo sábado à noite, na espera de que tal processo diminua a possibilidade de ocorrência de um bug maior.
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!
Marcadores: mysql sgdb crash recovery
