Nunca reinicie um mistério: o que registar antes de um reinício

Onde o reflexo está certo, e onde não está

Desligar e voltar a ligar funciona num web worker encravado, num consumidor de fila preso, num portátil. O estado que estava errado é descartado e reconstruído do nada, porque nada de valor vivia nele. Bases de dados, message brokers, storage daemons e tudo o que tenha um write-ahead log são o caso oposto. O estado é o produto. Um reinício não descarta o estado mau. Descarta a informação sobre como ficou mau, e em alguns engines acrescenta danos próprios.

O que um reinício apaga

A tabela de processos e os seus tempos: que processo corre desde quando, qual está em uninterruptible sleep e à espera de quê. O dono de cada socket e file handle aberto, que lhe diz quem segurava o lock ou a porta. O ring buffer do kernel, que numa instalação por omissão não sobrevive a um reboot e é onde um out-of-memory kill, um erro de filesystem ou um disco a falhar se anunciam. O conteúdo da memória do serviço, que um core dump pode preservar e um reinício não. A cronologia de encerramento e arranque que separa um crash de um arranque falhado. E num table engine sem crash recovery, a própria paragem suja é a forma como um cabeçalho de índice fica danificado, pelo que o reinício destinado a corrigir o serviço pode ser o evento que corrompe as tabelas.

O kit de evidências, em minutos

Tudo o que se segue é read-only. Execute-o a partir de uma shell na máquina, redirecione a saída para um ficheiro com marca temporal e copie esse ficheiro para fora da máquina antes de alguém tocar em mais alguma coisa.

$ uptime; last -x | head -20; journalctl --list-boots | tail -3
$ dmesg -T | tail -200
$ ps -eo pid,ppid,stat,etime,wchan:24,cmd --sort=-etime | head -60
$ ss -tnp state established | head -100
$ free -m; df -h; df -i
$ vmstat 1 5
$ top -b -n 1 | head -40

Para uma base de dados, acrescente a visão que o próprio engine tem de si mesmo enquanto ainda responde, e a cauda do seu error log quer responda quer não.

mysql> SHOW FULL PROCESSLIST;
mysql> SHOW ENGINE INNODB STATUS\G
mysql> SHOW GLOBAL STATUS LIKE 'Threads_%';
$ tail -500 /var/log/mariadb/mariadb.log

O primeiro bloco responde se a máquina já reiniciou, se o kernel matou alguma coisa, o que está preso e à espera de quê, quem detém que ligação, e se a máquina está sob pressão de memória ou de I/O. O segundo responde ao que a base de dados pensa que está a acontecer: uma transação longa a segurar locks, um thread de replicação parado, um deadlock, uma tabela reportada como crashed.

Crash, ou arranque falhado

A distinção mais útil no log é entre um serviço que teve um crash e um serviço que encerrou de forma limpa e depois não conseguiu voltar. O primeiro precisa de que o gatilho seja encontrado antes de se reiniciar o que quer que seja, porque reiniciar com um gatilho ativo reproduz o crash. O segundo é um problema de arranque ou de política: uma configuração alterada, um disco cheio, uma permissão, uma unit que não estava enabled. Os dados não estão em risco no segundo caso, e tratá-lo como um crash desperdiça o tempo que teria trazido o serviço de volta. A cauda do log do serviço mostra qual dos dois é: uma linha de encerramento concluído seguida de um abort no arranque é o segundo caso.

O caminho reversível

Assim que o gatilho é conhecido, a sequência é a mesma em todos os sistemas stateful. Pare o gatilho, para que a correção não possa ser desfeita por outro crash a meio da recuperação. Tire o snapshot gratuito: pare as escritas, renomeie o diretório de dados para o lado ou faça snapshot do volume, e guarde uma cópia fora da máquina. A partir desse ponto, cada passo pode ser revertido. Repare antes de fazer restore, porque um backup transporta fielmente o que o sistema transportava no momento em que foi feito, e se a falha entrou com os dados, o restore volta a plantá-la enquanto descarta tudo o que foi escrito desde então. Verifique na fronteira que falhou: a query que abortou, a tabela que reportou zero linhas, a posição de replicação, não apenas que a porta está aberta. Aplique o tuning planeado só depois de o paciente estar saudável. Recuperação e alteração são duas operações diferentes.

Uma contagem de linhas a zero depois de um hard reboot é habitualmente um índice danificado sobre linhas intactas. Em engines sem crash recovery, uma reparação reconstrói o índice a partir dos dados. Um restore deita os dados fora.

A cura, distinta da recuperação

Uma reparação é recuperação. A cura é remover o que quer que cause paragens sujas, e converter as tabelas que não sobrevivem a uma para um engine que sobrevive. Ambas pertencem ao seguimento, não ao combate ao incêndio.