MySQL Service Stop embora Restart = Always

Question

Eu tenho um Amazon t2.small EC2 - 1 Core e 2 GB de RAM que é mais do que os requisitos mínimos para o CentOS e o Virtualmin

Meu sistema:

• CentOS 7.5.1804
• Virtualmin
• MySQL 5.5.60-MariaDB
• Apache 2.4.6

O serviço MySQL sempre parou de funcionar um mês atrás depois de muitas visitas e eu posso reiniciá-lo novamente do Webmin até que li um artigo no blog DigitalOcean para adicionar o [ Restart = Always ] em o arquivo [ /etc/systemd/system/multi-user.target.wants/mariadb.service ] e eu testo isso matando o processo, então o serviço é reiniciado automaticamente No stop for 22 dias

Agora o serviço parou de funcionar novamente, eu abri o arquivo [mariadb.service] Eu encontrei a linha [Restart = Always] ainda lá, mas o serviço parou aleatoriamente.

Nota: Eu ainda posso iniciá-lo a partir do Webmin não há problema com isso, mas todos os sites ficam indisponíveis por causa da conexão com o banco de dados.

Eu preciso rastrear esse problema, mas não tenho experiência com esses problemas. Como resolver isso?

Configuração do MySQL: my.conf

symbolic-links=0
innodb_file_per_table = 1
myisam_sort_buffer_size = 8M
read_rnd_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
sort_buffer_size = 512K
table_open_cache = 64
max_allowed_packet = 1M
key_buffer_size = 16M

Algumas linhas de { var / log / messages }

Oct 22 16:49:49 ns1 kernel: Out of memory: Kill process 13092 (mysqld) score 97 or sacrifice child

Oct 22 16:49:49 ns1 kernel: Killed process 13092 (mysqld) total-vm:1065992kB, anon-rss:182972kB, file-rss:0kB, shmem-rss:0kB

Oct 22 16:49:49 ns1 kernel: [12822]    27 12822    28326       73      14        0             0 mysqld_safe


Oct 23 08:58:11 ns1 kernel: [12822]    27 12822    28326       74      14        0             0 mysqld_safe
Oct 23 08:58:11 ns1 kernel: [19703]    27 19703   266425    39874     150        0             0 mysqld

Oct 23 20:04:47 ns1 saslauthd[531]: do_auth         : auth failure: [user=mysql] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

Oct 23 22:21:25 ns1 kernel: [12822]    27 12822    28326       74      14        0             0 mysqld_safe
Oct 23 22:21:25 ns1 kernel: [19703]    27 19703   266425    48494     161        0             0 mysqld
Oct 23 22:21:25 ns1 kernel: Out of memory: Kill process 19703 (mysqld) score 103 or sacrifice child
Oct 23 22:21:25 ns1 kernel: Killed process 19703 (mysqld) total-vm:1065700kB, anon-rss:193976kB, file-rss:0kB, shmem-rss:0kB
Oct 23 22:21:25 ns1 kernel: [12822]    27 12822    28326       74      14        0             0 mysqld_safe
Oct 23 22:39:58 ns1 kernel: [12822]    27 12822    28326       76      14        0             0 mysqld_safe
Oct 23 22:39:58 ns1 kernel: [19246]    27 19246   266716    16891      98        0             0 mysqld
Oct 23 22:40:02 ns1 kernel: [12822]    27 12822    28326       76      14        0             0 mysqld_safe
Oct 23 22:40:02 ns1 kernel: [19246]    27 19246   266938    17064      98        0             0 mysqld
Oct 23 22:40:05 ns1 kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Oct 23 22:40:05 ns1 kernel: mysqld cpuset=/ mems_allowed=0
Oct 23 22:40:05 ns1 kernel: CPU: 0 PID: 19357 Comm: mysqld Kdump: loaded Not tainted 3.10.0-862.11.6.el7.x86_64 #1

    

Answer 1

Finalmente, eu encontrei a solução depois de 12 dias testando o início do MySQL depois de ser morto automaticamente com centenas de visitas de páginas.

A resposta depende da pergunta System OS (CentOS) e do serviço MySQL Mariadb

Solução: basta adicionar alguns segundos antes de iniciar o serviço. No meu caso, adicionei 45 segundos

Adicione as seguintes linhas na seção [service] em { /etc/systemd/system/multi-user.target.wants/mariadb.service } - É claro que o caminho depende do sistema operacional do sistema e nome do serviço MySQL (nem todos têm mariadb.service)

Restart=always
RestartSec=45s

NÃO esqueça de executar os seguintes comandos

sudo systemctl daemon-reload

sudo systemctl restart mariadb.service

    

Answer 2

Não faço ideia. Eu começaria com um tout dos suspeitos usuais

• verifique o status do espaço em disco apenas para estar seguro df -h e a memória free -m uptime (para verificar logo após uma falha)

• verifique se a propriedade e os direitos não foram alterados nos diretórios de dados

Answer 3

Desta linha na sua saída de log: Oct 22 16:49:49 ns1 kernel: Out of memory: Kill process 13092 (mysqld) score 97 or sacrifice child

Pode-se dizer que o seu systemd ficou sem memória e que o killer do Linux OOM (Out of memory) parou seu processo do mysqld (daemon do MySQL).

A partir da descrição da seção Restart = , está escrito que não reiniciará se the service is stopped with systemctl stop or an equivalent operation e talvez OOM killer forem equivalentes para systemd, isso eu não sei.

Seção perigosa

Parece que você pode desativar a OOM para o seu processo, adicionando OOMScoreAdjust=-1000 para desativar esta funcionalidade.