Hoje eu vi o MySQL/MariaDB parar de rodar em um CentOS VPS. Quando verifico o status, recebo:
# service mysql status
ERROR! MySQL is not running, but lock file (/var/lock/subsys/mysql) exists
Então eu removo esse arquivo e reinicio o serviço. Mas, no final do dia, o MySQL estará offline novamente e o arquivo de bloqueio ainda estará lá. Então, algo está acontecendo que está causando a morte do MySQL, mas deixe o arquivo de bloqueio, o que me diz que não é uma saída limpa/suave.
No passado, quando vi o arquivo de bloqueio existir, mas o serviço não estava sendo executado, foi porque todo o VPS teve uma reinicialização repentina. Mas este não é o caso aqui porque meu tempo de atividade é de mais de 160 dias no VPS.
Percebi a fail2banproibição de algumas tentativas aleatórias de hack em um site Wordpress no VPS hoje. Portanto, houve uma boa quantidade de tráfego tentando martelar o servidor aqui e ali até que eles fossem banidos automaticamente.
- Como posso determinar o que está fazendo com que o MySQL pare aleatoriamente?
- Qual é o método recomendado para reiniciar automaticamente o MySQL? Posso usar algo como Supervisor ?
ATUALIZAÇÃO: Depois de olhar meu messageslog, estou vendo isso:
Dec 1 14:06:42 localhost kernel: Out of memory: Kill process 25063 (mysqld) score 24 or sacrifice child
Dec 1 14:06:42 localhost kernel: Killed process 25063, UID 27, (mysqld) total-vm:773716kB, anon-rss:32300kB, file-rss:48kB
Então isso significa que o MySQL está simplesmente sendo sobrecarregado com solicitações (provavelmente do httpd)?
O OOM killer disparou quando o sistema estava sem RAM e swap - o
mysqldprocesso foi escolhido como sua vítima, provavelmente devido a uma combinação de alto uso de RAM e atividade relativamente baixa em sua RAM.Ajuste o tamanho do buffer pool disponível para fazer com que o MariaDB ocupe menos RAM e não acione o OOM killer (o que pode prejudicar o desempenho) ou forneça ao sistema mais RAM ou swap.