DBLog Table history is marked as crashed

[Ajuba]

Hallo
Nun hat es mich erwischt. Meine 9GB große Datenbank am QNAP NAS ist gecrashed.

Code Auswählen Erweitern

DBD::mysql::st execute_array failed: Table './fhem/history' is marked as crashed and last (automatic?) repair failed [err was 144 now 2000000000] executing 60711 generated 60711 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3241.- Frage 1: Macht bei dieser Fehlermeldung ein Reparaturversuch Sinn? Anm: Ich bin kein Datenbankexperte.

Ich habe ein Backup (set Rep.SQLDump dumpMySQL clientSide) bereit, das laut Logging ok sein müsste.

Code Auswählen Erweitern

2025.05.28 07:00:00 3: DbRep Rep.SQLDump - ################################################################
2025.05.28 07:00:00 3: DbRep Rep.SQLDump - ###             New database clientSide dump                 ###
2025.05.28 07:00:00 3: DbRep Rep.SQLDump - ################################################################
2025.05.28 15:32:55 3: DbRep Rep.SQLDump - Database dump finished successfully.
- Frage 2: Vor einem Einspielversuch des Backups wollte ich es mir mit einem Import in phpMyAdmin ansehen und habe die Begrenzung auf 2 GB übersehen. Nun läuft seit 24 Stunden eine Sanduhr und ich weiß nicht, wie ich das das abbreche, ohne eine riesige Datenleiche am NAS zu hinterlassen. Reicht phpMyAdmin beenden? Soll ich MariaDB am NAS neu starten?

- Frage 3: Falls die Empfehlung Richtung Restore geht, bitte ich um Tipps für so eine große DB.
Ich habe das Wiki studiert, aber noch einige Fragezeichen (z.B. Was ist bei ClientSide Dump zu beachten?, wo sollte das machen "Reopen-Zeit (siehe Einstellung Attribut "executeBeforeProc") sehr großzügig eingestellt" ?, ...

Besten Dank für Expertenratschläge im Voraus.

[DS_Starter]

Bin zwar kein Experte, aber ich würde so vorgehen ...
Eine MySQL-Datenbank mit einem solchen Fehler kann eventuell repariert werden. Hier sind einige mögliche Schritte:

Überprüfung des Problems Führe in der MySQL-Konsole oder einem Terminal den folgenden Befehl aus, um den Status der Tabelle zu prüfen:

Code Auswählen Erweitern

CHECK TABLE fhem.history;
Manuelle Reparatur Falls die automatische Reparatur fehlgeschlagen ist, kannst du versuchen, die Tabelle manuell zu reparieren:

Code Auswählen Erweitern

REPAIR TABLE fhem.history;
Falls das nicht funktioniert, probiere die Option USE_FRM:

Code Auswählen Erweitern

REPAIR TABLE fhem.history USE_FRM;

InnoDB-Tabellen? Falls die Tabelle das InnoDB-Format verwendet, funktionieren die obigen Befehle nicht. Dann kann es evtl. mit innodb_force_recovery klappen:

Code Auswählen Erweitern

sudo systemctl stop mysql
 sudo nano /etc/mysql/my.cnf  -> innodb_force_recovery = 1  einfügen
Werte von innodb_force_recovery reichen von 1 bis 6. Höhere Werte können Datenverlust riskieren, also    vorsichtig steigern:

    1: Nur minimale Wiederherstellung (sicherste Option)

    3: Mehr aggressive Wiederherstellung

    6: Letzte Option vor Datenverlust

Code Auswählen Erweitern

sudo systemctl start mysql
Später den Parameter wieder entfernen:

Code Auswählen Erweitern

sudo systemctl stop mysql
 sudo nano /etc/mysql/my.cnf  -> innodb_force_recovery = 1  löschen

Wenn das alles nicht hilft, dann Restore. Zunächst würde ich eine neue DB anlegen mit einem neuen DbLog als Kopie des bestehenden + Anpassung damit dein System erstmal normal weiterlaufen kann und loggt.

Dein bisheriges DbLog lässt du nichts mehr loggen (geht eh nicht) mit z.B.:

 

Code Auswählen Erweitern

attr <device> excludeDevs .*#.*
Nun kannst du mit diesem DbLog + DbRep "in Ruhe" restoren. Es wird bei der Größe vermutlich sehr lange, evtl. sogar Tage dauern je nach Leistungsfähigkeit deines Rechners. Stelle deswegen im DbRep das Attr timeout auf mehrere Tage, z.B. 604800. Das DbLog brauchst du nicht schließen, es loggt mit der obigen Einstellung nichts mehr, schreiben geht ohnehin nicht.

Wenn der Restore erfolgreich war, löscht du das excludeDevs wieder und dein DbLog sollte wieder loggen.
Die inzwischen in die neu angelegte DB gelaufenen Daten kannst du exportieren und in die restorte DB importieren. Steht im Wiki zu DbRep.

So könnte das ganze Verfahren funktionieren.

EDIT: Dann wäre natürlich mal die QNAP zu überprüfen. Ohne Grund crasht eine MariaDB üblicherweise nicht. Evtl. Plattenfehler vorhanden? Nur als Denkanstoß.

Grüße,
Heiko

[Ajuba]

   WOW - Du bist Spitze (dafür, dass du kein Experte bist  )

Code Auswählen Erweitern

CHECK TABLE fhem.history;Ergab

Code Auswählen Erweitern

Table Op Msg_type Msg_text
fhem.history check warning Table is marked as crashed and last repair failed
fhem.history check warning 1 client is using or hasn't closed the table prope...
fhem.history check warning Size of indexfile is: 473233408      Should be: 20...
fhem.history check error Record-count is not ok; is 46808071   Should be: 0
fhem.history check warning Found 46808071 key parts. Should be: 0
fhem.history check error Corrupt


Code Auswählen Erweitern

REPAIR TABLE fhem.history;ergab

Code Auswählen Erweitern

Table Op Msg_type Msg_text
fhem.history repair warning Number of rows changed from 1 to 46808072
fhem.history repair status OK
Im phpMyAdmin schauen die Ergebnisse vernünftig und vollständig aus und die Fhem Graphen sind auch OK.
Nur die Abfragezeiten sind viel höher als früher. Gibt's da eine Optimierung, die man drüber laufen lassen kann?

Deine restlichen Tipps (v.a.: neue DB mit neuem DBLog) muss ich noch in Ruhe studieren.

DANKE DANKE DANKE

[DS_Starter]

Erstmal erfreulich dass es funktioniert hat. 

Die erhöhten Abfragezeiten können daran liegen, dass der/die angelegten Index(e) nicht mehr passen.
Mit DbRep kannst du sie neu anlegen lassen:

 

Code Auswählen Erweitern

set ... index recreate_Report_Idx 

Vorher kannst du dir mit:

 

Code Auswählen Erweitern

set ... index list_all


alle vorhandenen Indexe anzeigen lassen und alle ersetzen.

Sollte das nicht helfen muß man mal Tante Google befragen, da wüsste ich auch nicht weiter.

Deine restlichen Tipps (v.a.: neue DB mit neuem DBLog) muss ich noch in Ruhe studieren.

Man kann grundsätzlich mehrere DbLog + DbRep mit verschiedenen Datenbanken gleichzeitig betreiben. In meiner Produktion habe ich drei ... für kurze Aufbewahrung (max. 180 Tage), eine für Langzeitdatenhaltung (Solarwerte) und eine für besondere Verwendung mit großer Spaltenbreite (Logging speziell für Syslog Collectoren).
So kann man sich z.B. eine Daten-Struktur aufbauen. Da gibt es natürlich viele Spielarten.


LG,
Heiko