Nunca reinicie un misterio: qué capturar antes de un reinicio

Dónde el reflejo acierta, y dónde no

Apagar y encender funciona con un worker web bloqueado, un consumidor de colas atascado, un portátil. El estado que estaba mal se descarta y se reconstruye desde cero, porque nada de valor vivía en él. Las bases de datos, los brokers de mensajes, los daemons de storage y cualquier cosa con un write-ahead log son el caso contrario. El estado es el producto. Un reinicio no descarta el estado malo; descarta la información sobre cómo llegó a estar mal, y en algunos motores añade daños propios.

Qué borra un reinicio

La tabla de procesos y sus tiempos: qué proceso lleva ejecutándose desde cuándo, cuál está en sueño ininterrumpible y sobre qué. El propietario de cada socket y descriptor de fichero abierto, que le dice quién retenía el lock o el puerto. El ring buffer del kernel, que en una instalación por defecto no sobrevive a un reinicio y es donde un out-of-memory kill, un error de sistema de ficheros o un disco que falla se anuncian. El contenido en memoria del servicio, que un core dump puede conservar y un reinicio no. La cronología de apagado y arranque que separa una caída de un arranque fallido. Y en un motor de tablas sin recuperación ante caídas, la propia parada no limpia es la forma en que se daña la cabecera de un índice, de modo que el reinicio que iba a arreglar el servicio puede ser el evento que corrompe las tablas.

El kit de pruebas, en minutos

Todo lo que sigue es de solo lectura. Ejecútelo desde una shell en la máquina, redirija la salida a un fichero con marca de tiempo, y copie ese fichero fuera de la máquina antes de que nadie toque nada más.

$ 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 una base de datos, añada la visión que el propio motor tiene de sí mismo mientras aún responde, y la cola de su registro de errores tanto si responde como si no.

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

El primer bloque responde si la máquina ya se ha reiniciado, si el kernel ha matado algo, qué está atascado y sobre qué, quién mantiene qué conexión, y si la máquina está bajo presión de memoria o de E/S. El segundo responde qué cree la base de datos que está pasando: una transacción larga que retiene locks, un hilo de replicación detenido, un deadlock, una tabla marcada como dañada.

Caída, o arranque fallido

La distinción más útil del registro es la que separa un servicio que se cayó de un servicio que se apagó limpiamente y después no consiguió volver. El primero necesita que se encuentre el desencadenante antes de reiniciar nada, porque reiniciar hacia un desencadenante activo reproduce la caída. El segundo es un problema de arranque o de política: una configuración cambiada, un disco lleno, un permiso, una unidad que no estaba habilitada. En el segundo caso los datos no corren riesgo, y tratarlo como una caída desperdicia el tiempo que habría devuelto el servicio. La cola del registro del servicio muestra cuál de los dos es: una línea de apagado completado seguida de un abort al arrancar es el segundo caso.

El camino reversible

Una vez conocido el desencadenante, la secuencia es la misma en todo sistema con estado. Detenga el desencadenante, para que la corrección no pueda deshacerse con otra caída a mitad de la recuperación. Tome el snapshot gratuito: detenga las escrituras, aparte el directorio de datos con un rename o haga un snapshot del volumen, y guarde una copia fuera de la máquina. A partir de ahí, cada paso puede revertirse. Repare antes de restaurar, porque un backup lleva fielmente lo que el sistema llevaba cuando se tomó, y si el fallo entró con los datos, el restore lo vuelve a plantar mientras descarta todo lo escrito desde entonces. Verifique en el límite que falló: la consulta que abortó, la tabla que informó de cero filas, la posición de replicación, no simplemente que el puerto está abierto. Despliegue el ajuste planificado solo cuando el paciente esté sano; recuperación y cambio son dos operaciones distintas.

Un recuento de filas a cero tras un reinicio brusco suele ser un índice dañado sobre filas intactas. En motores sin recuperación ante caídas, una reparación reconstruye el índice a partir de los datos; un restore tira los datos.

La cura, distinta de la recuperación

Una reparación es recuperación. La cura es eliminar lo que provoca paradas no limpias, y convertir las tablas que no pueden sobrevivir a una a un motor que sí puede. Ambas pertenecen al seguimiento, no al combate del incendio.