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 -u <> -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.

Nós mudamos!

Para ver o conteúdo desta matéria favor clicar no link abaixo


http://www.programabrasil.org/?p=46&utm_source=BlogSpot&
utm_medium=Materia&utm_term=Seguranca&utm_campaign=BlogSpot


ou aguarde enquanto o redirecionamos.

Muito obrigado e perdoe-nos por qualquer transtorno.

O evento durou dois dias, seu novo formato possibilitou com que, diferente do ano passado os palestrantes tivessem 30min extras na explicação de suas palestras, fazendo com que as palestras começassem em horários mais corretos. Mesmo com tal formato falhas ocorreram, como todo projeto a execução do evento teve alterações no decorrer da execução, a mais infeliz foi a falta do palestrante David Coallier por motivos de problemas no momento do embarque para o Brasil, o que fez o segundo dia começar com atraso e modificações nas primeiras horas do evento. Mesmo contando com tal situação a segunda parte do segundo dia correu de acordo com o planejado e tivemos a oportunidade de ver nomes como Manuel Lemos discorrer sobre o funcionamento do site phpClasses.org, Marcelo Araújo explicando sobre como desenvolver códigos em linguagem C para ser utilizado como funções em PHP, Igor Feghali comentando sobre suas experiências com o projeto PEAR, Guilherme Blanco, comentando sobre spyders e crowlers assim como Er Galvão Abbott apresentando importantes informações sobre segurança.

No primeiro dia tivemos a ausência de Willian Fernandes por motivos de saúdes, porem mesmo com tal inconveniente tivemos a nossa escolha diversos outros temas para acompanhar, em meu caso fui acompanhar a palestra de Márcio de Souza Pessoa, que falou sobre segurança em PHP, Souza esteve presente na CONISLI deste ano apresentando a palestra de segurança mas aproveitou o phpConference para lançar um livro sobre o assunto e dar mais detalhes pois sua palestra foi apresentada em dois horários sendo separada em duas partes. Tivemos realmente a falta de Willian no primeiro horário entretanto particularmente não observei nenhum problema que fizesse o evento perder fôlego ou brilho.

Ricardo Striquer Soares diretor de TI da empresa curitibana idéias.ual esteve presente para apresentar duas palestras, em uma das quais comentou sobre segurança para sistemas em PHP, Striquer explicou quais fatores de segurança levam um sistema a ser considerado inseguro e como proteger sistemas online de atacantes reais e comentou algumas situações ocorridas no passado sobre problemas que tem no dia-a-dia referente a segurança. "O evento é muito gratificante para nós profissionais, demonstra que o PHP está mais visível no mercado de trabalho e cresce cada vez mais sua importância na web brasileira ..." disse Striquer.

Eu pude ver a palestra de Lukas Smith e eles fez alguns comentários sobre o projeto PHP, eu tenho ultimamente tentado identificar um projeto livre com o qual eu me identificasse para poder contribuir com o mesmo e a palestra dele acredito será útil para que eu possa contribuir com o projeto PHP no futuro.

Também tive a oportunidade de ver a primeira parte da palestra do Manuel Lemos, que falou como ele trabalha a manutenção do site phpClass.org, nesta palestra ele fez alguns comentários sobre tecnologias que ele útiliza para manter o sistema rodando no ar.

abaixo algumas imagens do dia.