O MySQL voltou depois do reboot. A causa do incidente, não.

O chamado veio daquele jeito que ninguém de infra gosta de receber durante a madrugada: servidor de banco fora e aplicações dependentes indisponíveis.

O problema tinha sido percebido por volta de 00:40. Mais tarde, a situação piorou: o próprio host deixou de responder por SSH.

Sem acesso remoto, a equipe fez um reboot manual para recuperar o ambiente.

O servidor voltou. O MySQL subiu. As aplicações foram reportadas como restabelecidas.

Beleza.

Só que ainda tinha uma pergunta na mesa:

por que esse servidor travou?

07:23 parecia importante. Só não pelo motivo que parecia #

Depois da recuperação, o processo atual do MySQL aparecia iniciado às 07:23. Os logs disponíveis também mostravam um novo boot às 07:23:07.

Olhando só para o horário, dava para montar uma história errada e dizer que o MySQL tinha caído naquele momento.

Mas 07:23 era justamente o reboot realizado pela equipe porque o SSH já não respondia.

Ou seja:

era o horário da recuperação, não da falha original.

Log sem contexto também pode levar a uma conclusão errada.

Fomos no básico primeiro #

No estado encontrado depois do reboot:

• o filesystem principal estava em aproximadamente 58%;
• os inodes estavam em aproximadamente 1%;
• havia cerca de 29 GB de RAM no host;
• o processo mysqld apresentava aproximadamente 21 GiB de RSS;
• existia 2 GB de swap, sem uso naquele momento.

Disco cheio e esgotamento de inodes não explicavam o estado encontrado após a recuperação.

A memória chamou atenção, claro. O MySQL estava usando uma parcela grande da RAM disponível.

Mas calma lá:

pista não é causa raiz.

Esses números foram coletados depois do reboot. Eles não provam como o servidor estava às 00:40.

Procurar OOM e não encontrar não resolveu a dúvida #

A investigação procurou no kernel sinais como:

• oom;
• out of memory;
• killed process;
• erros de I/O;
• problemas de filesystem;
• segfault;
• mensagens relacionadas ao MySQL.

A busca não retornou ocorrências para a janela consultada.

Seria fácil concluir:

Não houve OOM.

Só que essa conclusão não se sustentava.

O próprio journalctl informou que os logs disponíveis começavam somente às 07:23:07 — depois do período que queríamos investigar.

Então a frase correta era outra:

Não havia evidência suficiente naquele journal para confirmar ou descartar OOM antes do reboot.

Parece detalhe. Não é.

O que dava para afirmar #

Até aquele ponto, a investigação sustentava que:

• houve indisponibilidade do servidor de banco;
• as aplicações dependentes foram reportadas como indisponíveis;
• o host deixou de responder via SSH;
• houve reboot manual de recuperação;
• o novo boot aparece às 07:23:07;
• o MySQL voltou a executar após o reboot;
• não havia falta de espaço ou de inodes no estado pós-recuperação;
• o journal disponível não cobria o período original da falha.

O que não dava para cravar #

Não havia evidência suficiente para atribuir a causa a:

• memória/OOM;
• CPU;
• I/O ou storage;
• MySQL/InnoDB;
• kernel;
• virtualização ou infraestrutura externa.

Todas permaneceram como possibilidades de investigação, não como conclusão.

O reboot resolveu uma coisa. A RCA era outra #

O reboot cumpriu o papel operacional: recuperar o serviço.

Isso não transforma reboot em diagnóstico.

A continuidade da investigação ficou dependente de fontes que poderiam ter sobrevivido ao reboot, como histórico de sar/sysstat, error log próprio do MySQL, logs tradicionais, monitoramento externo e eventos da camada de virtualização.

Sem essas evidências, qualquer causa definitiva seria chute.

No fim, a conclusão ficou do jeito que os dados permitiam:

serviço restabelecido. Causa raiz ainda não comprovada.

Sem inventar culpado só para fechar bonito.