Ne redémarrez jamais un mystère : quoi capturer avant un redémarrage

Là où le réflexe est juste, et là où il ne l'est pas

Éteindre et rallumer fonctionne sur un worker web bloqué, un consommateur de file coincé, un ordinateur portable. L'état qui était faux est jeté et reconstruit à partir de rien, parce que rien de valeur n'y vivait. Les bases de données, les brokers de messages, les démons de stockage et tout ce qui a un write-ahead log sont le cas inverse. L'état est le produit. Un redémarrage ne jette pas le mauvais état. Il jette l'information sur la façon dont il est devenu mauvais, et sur certains moteurs il ajoute ses propres dégâts.

Ce qu'un redémarrage efface

La table des processus et ses horodatages : quel processus tourne depuis quand, lequel est en sommeil ininterruptible et sur quoi. Le propriétaire de chaque socket ouvert et de chaque descripteur de fichier, qui vous dit qui tenait le verrou ou le port. Le ring buffer du noyau, qui sur une installation par défaut ne survit pas à un reboot et où un out-of-memory kill, une erreur de système de fichiers ou un disque défaillant s'annonce. Le contenu mémoire du service, qu'un core dump peut préserver et qu'un redémarrage ne peut pas. La chronologie d'arrêt et de démarrage qui distingue un crash d'un démarrage raté. Et sur un moteur de tables sans crash recovery, l'arrêt non propre lui-même est la façon dont un en-tête d'index s'abîme, de sorte que le redémarrage censé réparer le service peut être l'événement qui corrompt les tables.

Le kit de preuves, en quelques minutes

Tout ce qui suit est en lecture seule. Lancez-le depuis un shell sur la machine, redirigez la sortie vers un fichier horodaté, et copiez ce fichier hors de la machine avant que quiconque touche à autre chose.

$ 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

Pour une base de données, ajoutez la vue que le moteur a de lui-même tant qu'il répond encore, et la fin de son journal d'erreurs qu'il réponde ou non.

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

Le premier bloc répond à : la machine a-t-elle déjà redémarré, le noyau a-t-il tué quelque chose, qu'est-ce qui est bloqué et sur quoi, qui tient quelle connexion, et la machine est-elle sous pression mémoire ou I/O. Le second répond à ce que la base pense qu'il se passe : une longue transaction qui tient des verrous, un thread de réplication arrêté, un deadlock, une table signalée comme crashed.

Crash, ou démarrage raté

La distinction la plus utile dans le journal est celle entre un service qui a planté et un service qui s'est arrêté proprement puis n'a pas réussi à revenir. Le premier exige que le déclencheur soit trouvé avant tout redémarrage, parce que redémarrer dans un déclencheur encore actif reproduit le crash. Le second est un problème de démarrage ou de politique : une configuration modifiée, un disque plein, une permission, une unit qui n'était pas activée. Les données ne sont pas en danger dans le second cas, et le traiter comme un crash gaspille le temps qui aurait ramené le service. La fin du journal du service montre de quel cas il s'agit : une ligne d'arrêt terminé suivie d'un abort au démarrage est le second cas.

Le chemin réversible

Une fois le déclencheur connu, la séquence est la même sur tout système à état. Arrêtez le déclencheur, pour que la correction ne puisse pas être défaite par un autre crash en pleine reprise. Prenez le snapshot gratuit : arrêtez les écritures, renommez le répertoire de données à côté ou prenez un snapshot du volume, et gardez une copie hors de la machine. À partir de là, chaque étape peut être inversée. Réparez avant de restaurer, parce qu'une sauvegarde transporte fidèlement ce que le système transportait au moment où elle a été prise, et si le défaut est entré avec les données, la restauration le replante tout en jetant tout ce qui a été écrit depuis. Vérifiez à la frontière qui a échoué : la requête qui a avorté, la table qui a signalé zéro ligne, la position de réplication, pas simplement le fait que le port est ouvert. Déployez le tuning prévu seulement une fois le patient en bonne santé. Reprise et changement sont deux opérations différentes.

Un nombre de lignes tombé à zéro après un reboot brutal est en général un index abîmé au-dessus de lignes intactes. Sur les moteurs sans crash recovery, une réparation reconstruit l'index à partir des données. Une restauration jette les données.

Le remède, distinct de la reprise

Une réparation est une reprise. Le remède, c'est retirer ce qui provoque des arrêts non propres, et convertir les tables qui n'en supportent pas un seul vers un moteur qui le supporte. Les deux relèvent du suivi, pas de la lutte contre l'incendie.