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!