DBLog SQlite DB defekt

Jewe · 01 November 2023, 18:04:35

Hallo zusammen,

einer meiner SQlite DB´s hat es zerschossen. Heute hatte ich folgende im Log:

2023.10.31 23:23:57 2: DbRep Rep.impDbLog - ERROR - DBD::SQLite::st execute failed: database or disk is full at ./FHEM/93_DbRep.pm line 11677.

Dann hatte ich im DBLog-Device folgendes ausgeführt:

Code Auswählen

set Rep.impDbLog repairSQLite
Nun habe ich das im Log stehen:

Code Auswählen

2023.11.01 17:21:01 3: DbRep Rep.impDbLog - ################################################################
2023.11.01 17:21:01 3: DbRep Rep.impDbLog - ###                New SQLite repair attempt                 ###
2023.11.01 17:21:01 3: DbRep Rep.impDbLog - ################################################################
2023.11.01 17:21:01 3: DbRep Rep.impDbLog - start repair attempt of database /opt/fhem/important.db
2023.11.01 17:21:01 2: impDbLog - Connection closed until 03:21:01 (36000 seconds).
2023.11.01 17:21:01 3: DbRep Rep.impDbLog - execute command before repair: 'set impDbLog reopen 3600' 
2023.11.01 17:21:01 2: impDbLog - Connection closed until 18:21:01 (3600 seconds).
2023.11.01 17:21:02 3: impDbLog - Database disconnected by request.
2023.11.01 17:21:02 3: impDbLog - Database disconnected by request.
Error: near line 22451243: database or disk is full
Error: near line 22451244: database or disk is full
Error: near line 22451245: cannot commit - no transaction is active
2023.11.01 17:28:56 3: impDbLog - Reopen requested
2023.11.01 17:28:56 3: DbRep Rep.impDbLog - execute command after repair: 'set impDbLog reopen' 
2023.11.01 17:28:56 3: impDbLog - Reopen requested
2023.11.01 17:28:56 2: DbRep Rep.impDbLog - command message after repair: >Reopen executed.<
2023.11.01 17:28:56 3: impDbLog - Database disconnected by request.
2023.11.01 17:28:58 3: impDbLog - SubProcess connected to /opt/fhem/important.db
2023.11.01 17:28:58 2: impDbLog - Error: DBD::SQLite::db prepare failed: no such table: history [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 5005.

2023.11.01 17:28:59 3: impDbLog - Database disconnected by request.
2023.11.01 17:29:03 3: impDbLog - SubProcess connected to /opt/fhem/important.db
2023.11.01 17:29:03 2: impDbLog - Error: DBD::SQLite::db prepare failed: no such table: history [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 5005.

2023.11.01 17:29:11 3: impDbLog - SubProcess connected to /opt/fhem/important.db
2023.11.01 17:29:11 2: impDbLog - Error: DBD::SQLite::db prepare failed: no such table: history [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 5005.

Im Filesystem habe ich die Datei: important.db (4 KB) und important.db.corrupt (5.435.444 KB).

Vielleicht war die Idee mit repairSQLite doch nicht so gut?
Wie kann ich das nun noch retten, oder muss ich die DB aus der Sicherung holen, wobei ich dann mehrere Tage zurück gehen muss.

Danke, Jens

DS_Starter · 01 November 2023, 18:24:13

Hallo Jens,

deine primäre Fehlermeldung war ja "database or disk is full".
Wenn eine Korruption vorliegt kommt üblicherweise soweit ich es gesehen habe "database disk image is malformed".

Steht die Frage im Raum ob deine Disk tatsächlich voll ist bzw. nahezu voll ist.
Ohne genügend Freiplatz funktioniert auch die Reparatur nicht. Deine originale DB ist als "important.db.corrupt" abgelegt.

Diese Meldungen:

Code Auswählen

Error: near line 22451243: database or disk is full
Error: near line 22451244: database or disk is full

sind keine aus FHEM bzw. aus dem DbRep Modul.
Also ich vermute tatsächlich dass dein Filesystem vollgelaufen ist.

Jewe · 01 November 2023, 18:43:53

Hallo Heiko,

die SQLite-DB hat doch keine Größenbeschränkung, oder doch?

Das Filesystem hat genügent Platz 11GB.

Code Auswählen

jwe@fhem-vm:~$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            2,9G       0  2,9G    0% /dev
tmpfs           593M    524K  593M    1% /run
/dev/sda1        31G     18G   11G   63% /
tmpfs           2,9G       0  2,9G    0% /dev/shm
tmpfs           5,0M       0  5,0M    0% /run/lock
tmpfs           593M       0  593M    0% /run/user/1000

ZitatDeine originale DB ist als "important.db.corrupt" abgelegt.

Das heisst ich stoppe Fhem benenne die Datei um und starte wieder?

betateilchen · 01 November 2023, 18:51:07

Zitat von: Jewe am 01 November 2023, 18:43:53die SQLite-DB hat doch keine Größenbeschränkung, oder doch?

Doch. Aber von den 140 TB bist Du noch ein Stück weit entfernt.

Wie groß ist denn Dein sqlite File der Datenbank?

DS_Starter · 01 November 2023, 19:00:42

ZitatDas heisst ich stoppe Fhem benenne die Datei um und starte wieder?

Ja, kannst du machen und sollte funktionieren. Allerdings wirst du vermutlich wieder auf eine Fehlermeldung stoßen wenn das ursächlich Problem nicht beseitigt wird.

Dein File ist ca. 5,5 GB groß wenn ich richtig gesehen habe. Bei der Reparatur wird derselbe Platz (vielleicht etwas mehr) temporär zusätzlich benötigt.
Vllt. war das Filesystem dann tatsächlich voll. Kann nur mutmaßen.

betateilchen setzt selbst SQLite ein und hat mehr Erfahrung mit dieser DB als ich.

Jewe · 01 November 2023, 19:36:23

Ja, die Datei ist knapp 5,5 GB groß. Auf den Filessystem sind noch 11GB frei, das sollte dann doch reichen.
Ok also ich werde nun erstmal die DB wieder ans laufen bringen.

Mein Plan ist dass ich meine beiden SQLite Dateien zusammenführe und das dann auf InfluDB oder MAriaDB umstelle. Allerdings bin ich mir nicht sicher welches System das bessere ist, wenn man das so überhaput sagen kann.
Einen Versuch hatte ich von eon paar Wochen mal mit InfluxDB gemacht. In diese DB logge ich noch ein paar Daten zusätzlich als Test. Meine Daten aus der SQLite konnte ich noch nicht in dieser InfluxDB einspielen, da ich es noch nocht geschafft habe das Format richtig zu generieren...

betateilchen · 01 November 2023, 20:53:09

Zitat von: Jewe am 01 November 2023, 19:36:23Mein Plan ist dass ich meine beiden SQLite Dateien zusammenführe und das dann auf InfluDB oder MAriaDB umstelle. Allerdings bin ich mir nicht sicher welches System das bessere ist, wenn man das so überhaput sagen kann.

Ich sag mal so: Bei dieser Entscheidung geht es m.E. nicht um "das Bessere" sondern darum, zu welchem System Du hier bei Problemen schnellere Hilfe bekommst. Und da liegt MariaDB sicherlich ein ganzes Stück weit vorne, weil es einfach "üblicher" ist.

Bei Deinem geplanten Umzug kann Dir sicher DbRep sehr viel helfen und einiges einfacher machen.

Jewe · 01 November 2023, 21:29:55

Also so wie es aussieht funktiniert nun die DB wieder so wie sie soll. Auch ein dump of Database funktiniert wieder ohne die Disk full Meldung. Kann mir das im Moment nicht erklären, da genügend Platz vorhanden ist.

Diese Meldung habe ich nach dem Dump bekommen:

Code Auswählen

WARNING - dump finished, but message after command appearedKann aber im Log nichts finden:

Code Auswählen

2023.11.01 21:05:20 3: DbRep Rep.impDbLog - ################################################################
2023.11.01 21:05:20 3: DbRep Rep.impDbLog - ###                    New SQLite dump                       ###
2023.11.01 21:05:20 3: DbRep Rep.impDbLog - ################################################################
2023.11.01 21:05:20 3: DbRep Rep.impDbLog - execute command before dump: 'set impDbLog reopen 3600' 
2023.11.01 21:05:20 2: impDbLog - Connection closed until 22:05:20 (3600 seconds).
2023.11.01 21:05:20 3: impDbLog - Database disconnected by request.
2023.11.01 21:05:20 3: DbRep Rep.impDbLog - Size of database /opt/fhem/important.db before optimize (MB): 5308.05 MB
2023.11.01 21:05:20 3: DbRep Rep.impDbLog - VACUUM database /opt/fhem/important.db....
2023.11.01 21:10:07 3: DbRep Rep.impDbLog - Size of database /opt/fhem/important.db after optimize (MB): 5290.75 MB
2023.11.01 21:10:07 3: DbRep Rep.impDbLog - Starting dump of database 'important.db'
2023.11.01 21:11:05 3: DbRep Rep.impDbLog - Size of backupfile: 5290.75 MB
2023.11.01 21:11:06 3: DbRep Rep.impDbLog - Finished backup of database important - total time used (hh:mm:ss): 00:05:45
2023.11.01 21:11:06 3: DbRep Rep.impDbLog - execute command after dump: 'set impDbLog reopen' 
2023.11.01 21:11:06 3: impDbLog - Reopen requested
2023.11.01 21:11:06 2: DbRep Rep.impDbLog - command message after dump: >Reopen executed.<
2023.11.01 21:11:06 3: DbRep Rep.impDbLog - Database dump finished successfully. 
2023.11.01 21:11:06 3: impDbLog - Database disconnected by request.
2023.11.01 21:11:06 3: impDbLog - SubProcess connected to /opt/fhem/important.db

Was ich mich allerdings Frage ist, ob die attribute so sinnvoll sind:

Code Auswählen

attr Rep.impDbLog executeAfterProc set impDbLog reopen
attr Rep.impDbLog executeBeforeProc set impDbLog reopen 3600

Den reopen macht DBrep doch nach dem Dump automatisch.

Zitat...Und da liegt MariaDB sicherlich ein ganzes Stück weit vorne, weil es einfach "üblicher" ist...

Ja das denke ich auch, InfluxDB wird eben mit Grafana oft verwendet und entsprechend gehypt.
Ich habe Fhem in einer VM unter Proxmox laufen, würdet Ihr da MariaDB auf der selben VM installieren oder in einen eigenen Container packen? Letzteres kann aber auch wieder mehr probleme machen.

betateilchen · 01 November 2023, 21:35:34

Zitat von: Jewe am 01 November 2023, 21:29:55Diese Meldung habe ich nach dem Dump bekommen:
Code Auswählen Erweitern
WARNING - dump finished, but message after command appeared

Kannst Du ignorieren. Das ist schlichtweg die Meldung vom reopen.

Zitat von: Jewe am 01 November 2023, 21:29:55Ich habe Fhem in einer VM unter Proxmox laufen, würdet Ihr da MariaDB auf der selben VM installieren oder in einen eigenen Container packen?

Hier läuft FHEM auch in einer VM unter Proxmox.

Und wenn ich die Anforderung hätte, eine MariaDB unterzubringen, würde ich das in einer eigenen VM auf der Proxmox Kiste machen, nicht in einem Container.

Bei mir läuft MariaDB auf einer Lightsail Instanz bei Amazon. Insbesondere, weil ich auf die Logs auch von anderer Stelle als von zuhause aus zugreifen muss.

Jewe · 02 November 2023, 14:31:12

update und Danke.

Gestern hat der Dump von Hand gesteartet funktioniert, da hatte ich aber auch ein paar alte Log usw. gelöscht. Heute Nacht dann wieder nicht. Also reichen die 11GB nicht aus dass der Dump erstellt werde kann oder ich bin genau an der Grenze.
Habe Heute mal die Dsik vergrößert und nun läuft es (von Hand) wieder, Denke auch heute Nacht...

Werde nun eine VM für MariaDB aufsetzen und dann versuchen die Daten zu übernehmen. Der Export sollte nun auch funktionieren, da in jedem fall genügend Platz da ist.