Kein Neustart für ein Rätsel: was Sie vor einem Restart sichern sollten

Wo der Reflex richtig ist, und wo nicht

Aus- und wieder einschalten funktioniert bei einem festgefahrenen Web-Worker, einem hängenden Queue-Consumer, einem Laptop. Der Zustand, der falsch war, wird verworfen und von Grund auf neu aufgebaut, weil nichts von Wert darin lebte. Datenbanken, Message Broker, Storage-Daemons und alles mit einem Write-Ahead-Log sind der gegenteilige Fall. Der Zustand ist das Produkt. Ein Neustart verwirft nicht den schlechten Zustand. Er verwirft die Information darüber, wie er schlecht wurde, und auf manchen Engines fügt er eigenen Schaden hinzu.

Was ein Neustart löscht

Die Prozesstabelle und ihre Zeiten: welcher Prozess seit wann läuft, welcher sich in einem Uninterruptible Sleep befindet und worauf. Den Inhaber jedes offenen Sockets und File Handles, der Ihnen sagt, wer den Lock oder den Port gehalten hat. Den Ring Buffer des Kernels, der auf einer Standardinstallation einen Reboot nicht überlebt und der Ort ist, an dem sich ein Out-of-Memory-Kill, ein Dateisystemfehler oder eine sterbende Platte ankündigt. Den Speicherinhalt des Dienstes, den ein Core Dump bewahren kann und ein Neustart nicht. Die Zeitlinie von Shutdown und Boot, die einen Crash von einem fehlgeschlagenen Start unterscheidet. Und auf einer Table Engine ohne Crash Recovery ist der unsaubere Stopp selbst der Weg, auf dem ein Index-Header beschädigt wird, sodass der Neustart, der den Dienst reparieren sollte, das Ereignis sein kann, das die Tabellen korrumpiert.

Das Beweismittel-Kit, in Minuten

Alles unten ist read-only. Führen Sie es aus einer Shell auf der Maschine aus, leiten Sie die Ausgabe in eine Datei mit Zeitstempel um, und kopieren Sie diese Datei von der Maschine herunter, bevor irgendjemand etwas anderes anfasst.

$ 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

Bei einer Datenbank kommt die Sicht der Engine auf sich selbst dazu, solange sie noch antwortet, und das Ende ihres Error-Logs, ob sie antwortet oder nicht.

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

Der erste Block beantwortet, ob die Maschine bereits neu gestartet wurde, ob der Kernel etwas beendet hat, was hängt und worauf, wer welche Verbindung hält, und ob die Maschine unter Speicher- oder I/O-Druck steht. Der zweite beantwortet, was die Datenbank glaubt, was gerade passiert: eine lange Transaktion, die Locks hält, ein gestoppter Replikations-Thread, ein Deadlock, eine als crashed gemeldete Tabelle.

Crash, oder fehlgeschlagener Start

Die nützlichste Unterscheidung im Log ist die zwischen einem Dienst, der abgestürzt ist, und einem Dienst, der sauber heruntergefahren wurde und dann nicht wieder hochkam. Beim ersten muss der Auslöser gefunden werden, bevor irgendetwas neu gestartet wird, denn ein Neustart in einen lebenden Auslöser hinein reproduziert den Crash. Der zweite ist ein Start- oder Richtlinienproblem: eine geänderte Konfiguration, eine volle Platte, eine Berechtigung, ein Unit, das nicht aktiviert war. Im zweiten Fall sind die Daten nicht in Gefahr, und ihn wie einen Crash zu behandeln verschwendet die Zeit, die den Dienst zurückgebracht hätte. Das Ende des Dienst-Logs zeigt, welcher von beiden es ist: Eine Zeile «shutdown complete», gefolgt von einem Abbruch beim Start, ist der zweite Fall.

Der umkehrbare Weg

Sobald der Auslöser bekannt ist, ist die Reihenfolge auf jedem zustandsbehafteten System dieselbe. Stoppen Sie den Auslöser, damit die Reparatur nicht durch einen weiteren Crash mitten in der Wiederherstellung zunichtegemacht werden kann. Nehmen Sie den kostenlosen Snapshot: Schreibzugriffe stoppen, das Datenverzeichnis beiseite umbenennen oder das Volume snapshotten, und eine Kopie außerhalb der Maschine aufbewahren. Ab diesem Punkt lässt sich jeder Schritt rückgängig machen. Reparieren Sie, bevor Sie wiederherstellen, denn ein Backup trägt getreu das, was das System zum Zeitpunkt der Sicherung getragen hat, und wenn der Fehler mit den Daten hineingekommen ist, pflanzt der Restore ihn wieder ein und verwirft alles, was seitdem geschrieben wurde. Verifizieren Sie an der Grenze, die versagt hat: die Abfrage, die abgebrochen ist, die Tabelle, die null Zeilen gemeldet hat, die Replikationsposition, nicht nur, dass der Port offen ist. Spielen Sie das geplante Tuning erst ein, wenn der Patient gesund ist. Wiederherstellung und Änderung sind zwei verschiedene Eingriffe.

Eine auf null gefallene Zeilenzahl nach einem harten Reboot ist meist ein beschädigter Index über intakten Zeilen. Auf Engines ohne Crash Recovery baut eine Reparatur den Index aus den Daten neu auf. Ein Restore wirft die Daten weg.

Die Heilung, im Unterschied zur Wiederherstellung

Eine Reparatur ist Wiederherstellung. Die Heilung besteht darin, das zu beseitigen, was unsaubere Stopps verursacht, und Tabellen, die keinen überstehen, auf eine Engine umzustellen, die es kann. Beides gehört in die Nachbereitung, nicht in die Brandbekämpfung.