Woran erkennt man, dass ein Datenbank-Container durch einen Stromausfall beschädigt wurde?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

What Are the Warning Signs That a Database Container Was Corrupted by Power Loss?

Gehen Sie von einer Beschädigung aus, wenn die Datenbank die normale Absturz-Wiederherstellung nicht abschließen kann oder danach Inkonsistenzen bei Prüfsummen, Seiten, Protokollsequenzen, Tabellen oder Indizes meldet.

Ein unsauberes Herunterfahren bedeutet nicht automatisch, dass die Datenbank beschädigt ist; PostgreSQL, MySQL, MariaDB und ähnliche Engines verwenden Journale oder Write-Ahead-Logs gezielt, um den festgeschriebenen Zustand wiederherzustellen. Die kritische Grenze ist erreicht, wenn die Wiederherstellung wiederholt wird, die Engine beendet wird, dieselbe Abfrage auf ungültige Seiten trifft, Prüfsummen fehlschlagen, Tabellen verschwinden, Indizes den Tabellendaten widersprechen oder Backups und Integritätsprüfungen den Cluster nicht konsistent lesen können.

Normale Absturz-Wiederherstellung von einer Wiederherstellungsschleife unterscheiden

Bewahren Sie das erste Startprotokoll nach der Wiederherstellung der Stromversorgung auf. Notieren Sie, ob die Engine die Protokolle einmal wiedergibt und anschließend betriebsbereit wird oder ob sie wiederholt neu startet, in eine erzwungene Wiederherstellung wechselt oder am selben Datensatz oder auf derselben Seite anhält.

InnoDB kann nach einem unterbrochenen Schreibvorgang die Wiederherstellung möglicherweise teilweise geschriebener Seiten melden; diese Meldung zeigt an, dass die Engine versucht, eine sichere Absturz-Wiederherstellung durchzuführen. Wiederholte Fehler können jedoch auf InnoDB-Fehler nach einem Stromausfall hindeuten.

Eine einmalig erfolgreiche Wiederherstellung mit anschließend normalen Prüfungen ist kein Beweis für eine Beschädigung. Eine Schleife, eine schwerwiegende Assertion, ein wiederholtes Signal oder die Unfähigkeit, den betriebsbereiten Zustand zu erreichen, ist ein klares Signal, das Kopieren von Rohdateien und das Testen von Backups durchzuführen, bevor weitere Schreibvorgänge erfolgen.

Auf Prüfsummen- und Fehler bei ungültigen Seiten achten

Durchsuchen Sie die Protokolle nach „checksum mismatch“, „page verification failed“, „invalid page in block“, „corrupt page“, „short read“, „bad magic number“ oder „unexpected end-of-file“. Notieren Sie die genannte Relation, Tabelle, den Block oder den Tablespace.

pganalyze zeigt, wie sich eine Beschädigung in PostgreSQL durch Fehler bei Seitenprüfsummen äußert, gefolgt von einem Fehler wegen einer ungültigen Seite, wenn der beschädigte Block gelesen wird.

Unterdrücken Sie den Fehler nicht und setzen Sie beschädigte Seiten nicht auf null, bevor Sie Beweise gesichert und die Backup-Abdeckung bestätigt haben. Wenn derselbe Block bei mehreren Neustarts fehlschlägt, ist dies ein stärkerer Hinweis als ein einmaliges Timeout der Anwendung.

Auf Abfragen achten, die nur bei bestimmten Zeilen oder Tabellen fehlschlagen

Führen Sie schreibgeschützte Prüfungen für die Tabellen und Abfragen durch, die die Anwendung normalerweise verwendet. Eine Beschädigung kann verborgen bleiben, bis ein Scan, VACUUM, ein Backup oder eine Anfrage auf eine beschädigte Seite zugreift.

Eine PostgreSQL-Analyse erklärt, dass eine nicht übereinstimmende Prüfsumme auf ein Problem unterhalb der Datenbank hindeutet, während eine ungültige Seite ohne Prüfsummenwarnung weiterhin auf einen Speicher-, Arbeitsspeicher-, Dateisystem- oder versehentlichen Dateischaden zurückzuführen sein kann. Das praktische Symptom ist ein reproduzierbarer Lesevorgang mit ungültiger Seite bei gewöhnlichen Abfragen.

Notieren Sie genau, welche Abfrage und welches Objekt fehlschlagen. Lassen Sie die Anwendung keine umfangreichen Schreibvorgänge fortsetzen, solange nur ein Teil der Datenbank lesbar ist, da neue Zustände die Wiederherstellung und Backups erschweren können.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Auf Inkonsistenzen bei Indizes, Transaktionen und Metadaten prüfen

Zu den Warnzeichen gehören doppelte Schlüssel, die einen eindeutigen Index verletzen, fehlende Zeilen, die über einen Zugriffspfad erreichbar sind, über einen anderen jedoch nicht, ungültige Transaktions-IDs, beschädigte TOAST- oder Blöcke großer Werte sowie Indizes, deren Validierung fehlschlägt.

Credativ weist in seiner Analyse von Beschädigungen darauf hin, dass Cluster ohne Datenprüfsummen Schäden durch Fehler auf niedriger Ebene anzeigen können, etwa durch ungültige Seiten, Probleme mit Transaktions-IDs, TOAST-Inkonsistenzen oder Abstürze des Backends. Einige dateibasierte Backups können beschädigte Seiten sichern, ohne sie zu erkennen.

Führen Sie unterstützte Integritäts- und Indexprüfungen auf einer Kopie oder während eines kontrollierten Wartungsfensters durch. Eine Neuerstellung des Index kann einen beschädigten abgeleiteten Index reparieren, behebt jedoch keine beschädigten Tabellendaten oder den zugrunde liegenden Speicherschaden.

Datenbankfehler mit Warnungen von Dateisystem und Speicher korrelieren

Prüfen Sie die Protokolle des Host-Kernels, Dateisystems, Speicherpools, Laufwerks, Controllers, der USV und der Container-Laufzeit rund um den Ausfall. Achten Sie auf E/A-Fehler, Zurücksetzungen, Prüfsummenfehler, erneute Einbindungen im Nur-Lese-Modus, degradierte Pools sowie verlorene oder abgeschnittene Dateien.

Ein Leitfaden zur Datenbankwiederherstellung weist darauf hin, dass Stromausfälle und fehlerhafter Arbeitsspeicher beschädigte Seitenschreibvorgänge verursachen können, insbesondere wenn sich das Speicherverhalten nicht mit den Dauerhaftigkeitsannahmen der Datenbank deckt. Diese Ereignisse auf Host-Ebene helfen dabei, InnoDB-Seitenbeschädigungen von einem normalen Neustart der Anwendung zu unterscheiden.

Beheben Sie das Speicherproblem, bevor Sie eine fehlerfreie Datenbank darauf wiederherstellen. Eine erfolgreiche logische Wiederherstellung auf fehlerhaften Medien kann den Vorfall erneut auslösen oder den Ersatz unbemerkt beschädigen.

Schreibvorgänge stoppen und die Wiederherstellung aus einem fehlerfreien Backup nachweisen

Wenn sich Anzeichen einer Beschädigung wiederholen, stoppen Sie abhängige Anwendungen, erstellen Sie, sofern sicher möglich, einen Snapshot oder Klon des betroffenen Volumes und bewahren Sie Protokolle und Konfiguration auf. Testen Sie das aktuellste Backup auf einem separaten Speicher, bevor Sie den ursprünglichen Cluster verändern.

Die ZimaSpace-Checkliste für das Sichern des Zustands von Docker-Anwendungen legt fest, was vor einem destruktiven Versuch zur Datenbankwiederherstellung vorhanden sein muss.

Das System ist erst dann vertrauenswürdig, wenn die wiederhergestellte Datenbank sauber startet, Integritätsprüfungen bestehen, repräsentative Abfragen und Schreibvorgänge erfolgreich sind, Backups abgeschlossen werden und der Host-Speicher keine neuen Fehler meldet. Modi zur erzwungenen Wiederherstellung sollten zur Datenrettung im Rahmen eines dokumentierten Wiederherstellungsplans verwendet werden, nicht im normalen Betrieb.