Reinicializa automaticamente o mysql quando morre

Question

Eu tenho um servidor rackspace que venho alugando para executar meus projetos pessoais. Desde que eu sou barato, tem 256Mb de RAM e honestamente não pode lidar com muito. De vez em quando, quando há um aumento acentuado no tráfego, o servidor decide começar a matar processos e parece que o mysqld é popular para ser eliminado. Eu tento visitar o meu site e sou saudado com a mensagem de que houve um erro ao estabelecer a conexão com o banco de dados. A inspeção dos logs revela que o mysqld foi morto devido à falta de memória.

Como eu ainda sou tão pobre quanto estava ontem e não quero atualizar a memória RAM da minha VM rackspace, há uma maneira que eu possa dizer para reinicializar automaticamente o mysqld quando ele morrer?

Eu tenho um pensamento para usar algo como crontab, mas, infelizmente, eu não sei exatamente o que fazer lá também. Eu acho que sou produto da geração "Linux no seu desktop" já que posso fazer a maioria das coisas no meu desktop e laptop (que rodam Linux quase que exclusivamente), mas ainda falta muitas habilidades de administração de servidor para Linux.

O servidor roda o CentOS 6.3

    

Answer 1

Esta não é uma solução limpa, obviamente seria melhor evitar o problema em primeiro lugar. De qualquer forma, não tenho certeza de como o CentOS gerencia serviços, mas acho que ele usa service . Em caso afirmativo, você pode verificar se o serviço mysql está sendo executado com

/sbin/service mysql status

Este comando sairá com êxito se mysql estiver em execução e retornar um status de saída não 0, se i não estiver. Você pode, portanto, iniciar o serviço se ele não estiver sendo executado com este comando:

/sbin/service mysql status || service mysql start

Você pode adicionar esta linha a /etc/crontab para iniciar o comando a cada minuto:

* * * * * /sbin/service mysql status || service mysql start

    

Answer 2

Isso é um pouco perturbador.

O

mysqld é sempre reiniciado por mysqld_safe porque existe um loop infinito na parte inferior de mysqld_safe para verificar desligamentos anormais. Se o erro for muito grave, nem mesmo mysqld_safe poderá reiniciar mysqld nas tentativas subsequentes.

Dada a situação para a qual mysqld_safe foi projetado, talvez não seja uma boa ideia forçar mysqld a iniciar se mysqld_safe a rejeitar de qualquer maneira.

Você precisa localizar o log de erros em my.cnf em

[mysqld]
log-error=log-filename

ou

[mysqld_safe]
log-error=log-filename

Leia o arquivo de texto (provavelmente executando tail -30 log-filename ) e encontre a origem do processamento do mysqld sendo encerrado.

    

Answer 3

Em uma tentativa de força bruta para manter as coisas funcionando em um VPS com pouca memória, usei uma modificação da resposta da terdom a> para verificar e reiniciar o MySQL.

/sbin/service mysqld status || service mysqld restart

Eu precisava alterar mysql para mysqld para que funcionasse. Sem isso, eu receberia o erro " ERROR! MySQL is running but PID file could not be found ".

No meu sistema CentOS 7.2, /sbin/service redireciona para /bin/systemctl status , então o comando a seguir é mais rápido de executar.

/bin/systemctl status  mysqld.service || /bin/systemctl start  mysqld.service

Acabei de adicionar a seguinte linha ao crontab raiz do sistema. Ele verifica cada minuto se o MySQL está rodando e redireciona o stdout para null. Iniciar o serviço não produzirá nada a menos que algo dê errado, portanto, não há necessidade de adicionar o redirecionamento nulo no último comando.

* * * * * /bin/systemctl status mysqld.service > /dev/null || /bin/systemctl start  mysqld.service

O pipe duplo || significa OR e executará o segundo comando se o primeiro comando falhar de alguma forma. (Retorna um código de saída maior que zero.)

É como dizer: "Execute o primeiro comando, ou , se o primeiro comando falhar de alguma forma, execute o segundo comando".

Isso é diferente do duplo e comercial && , que é como dizer: "Execute o primeiro comando, e , somente se o primeiro comando for bem-sucedido, execute o segundo comando".

    

Answer 4

O seguinte é de jonnyreeves.co .uk :

E o culpado é o php-fpm! Um rápido google encontrou outro cliente Wordpress sofrendo de sintomas semelhantes; O conselho era ajustar a configuração do pool php-fpm (/etc/php-fpm.d/www.conf) e ajustar a configuração do pm. A principal mudança foi passar de pm = dynamic para pm = ondemand com um valor pm.max_children de 5 (com base na observação de ~ 5% de uso de memória por trabalhador). Depois de alterar a configuração, reiniciei todos os serviços e verifiquei o uso da memória.

service php-fpm restart
service nginx restart
service mariadb restart

Depois de reiniciar, o uso de memória foi drasticamente menor.