93_DbLog Fehlermeldung während sqlite Dump mit DbRep

[pechnase]

Hallo zusammen,

mit dem Jahreswechsel 2017/2018 habe ich meine FileLogs auf DbLog umgestellt. Davon auch betroffen ca. 40 SVG-Plots.
Ich verwende sqlite als DB auf einem Raspberry Pi 2B. Der Umstieg hat ganz gut geklappt, ich habe dabei viel gelernt!

Zur Sicherung der DB mache ich jede Nacht um 1:45 getriggert über ein 'at' mit DbRep ein Backup der DB. Im fhem.log finde ich bei jedem Backup folgende Fehlermeldung:

2018.02.09 01:46:22 2: DbLog WhngDB -> Error table history - DBD::SQLite::st execute_array failed: executing 9 generated 1 errors at ./FHEM/93_DbLog.pm line 1978

Das System läuft zwar trotzdem normal, das Backup wird auch angelegt, micht 'stört' aber die Fehlermeldung

Ich kann die Ursache, trotz intensiever Suche hier im Forum, einfach nicht finden. Vielleicht kann mir jemand einen Tipp geben.

Ein configCheck der DB ist fehlerlos.

FHEM ist auf dem neuesten Stand: DbLog V3.84, DbRep 7.8.1
Hier die Konfigurationen für die Db:

Code Auswählen Erweitern


defmod WhngDB DbLog ./db.conf .*:.*
attr WhngDB DbLogSelectionMode Include
attr WhngDB DbLogType History
attr WhngDB asyncMode 1
attr WhngDB cacheEvents 1
attr WhngDB cacheLimit 500
attr WhngDB disable 0
attr WhngDB room DB
attr WhngDB showproctime 1
attr WhngDB shutdownWait 2
attr WhngDB syncInterval 30
attr WhngDB userReadings DbFileSize:reduceLogState.* {  (split(' ',`du -m /usb-speicher/FHEM_DB/fhem.db`))[0]  }


und für das Backup:

Code Auswählen Erweitern


defmod BackupDb DbRep WhngDB
attr BackupDb dumpDirLocal /nas/fhembackup/fhem/
attr BackupDb dumpFilesKeep 10
attr BackupDb executeAfterProc { my $duration = ReadingsVal("BackupDb","background_processing_time"," ");;;; exmail('smarthome@domain.de','Backup DB Ende','Backup DB wurde nach ' .$duration. ' sec. beendet') }
attr BackupDb executeBeforeProc { exmail('smarthome@domain.de','Backup DB Start','Backup DB wurde gestartet') }
attr BackupDb optimizeTablesBeforeDump 1
attr BackupDb room DB
attr BackupDb showproctime 1
attr BackupDb verbose 0


Das 'at' sieht so aus:

Code Auswählen Erweitern


defmod BackupDbTrigger at *01:45:00 set BackupDb dumpSQLite
attr BackupDbTrigger room DB


Die Backup 'background_processing_time' beträgt ca. 220sec. Die DB ist ca. 200MB groß. Eine 1/2h vor dem Backup 'säubere' ich die Db auch mit DbRep von Werten älter 10 Tagen von Thermostaten, Temperaturfühlern usw.

Vielleicht hat einer das gleiche Problem und kann mir einen Tipp geben.

Vielen Dank
Wolfgang

[DS_Starter]

Hallo Wolfgang,

die Meldung besagt, dass 9 Datensätze in die DB eingefügt werden sollten, aber bei einem Datensatz ein Fehler generiert wurde den die DB meldet.
DbRep verwendet zwar die Online Backup API von SQLite, aber möglicherweise gibt es ja Zustände, die während des Backup einen fehlerhaften Insert verursachen.
Für die Applikation ist das nicht weiter problematisch, da in diesem Fall die Datensätze wieder in den Cache eingefügt werden um sie beim nächsten Sync erneut zu schreiben.

Wenn dich diese Meldung stört, könnstest du deine Attribute executeBeforeProc / executeAfterProc  erweitern um während des Backups das Logging in die DB zu vermeiden:

Code Auswählen Erweitern


executeBeforeProc  -> set DbLog reopen 1800
executeAfterProc   ->  set DbLog reopen


(Das ist jetzt nur der Hinweis welche Befehle angewendet werden, nicht korrekt codiert !)


LG,
Heiko

[pechnase]

Hallo Heiko,

danke für die schnelle Antwort und die Erklärung. Dann kann ich ja beruhigt mit der Fehlermeldung leben. Evtl. baue ich Deinen Vorschlag mit ein.

LG Wolfgang

[DS_Starter]

Kleiner Nachtrag,

ich hatte ja noch gesehen, dass vor dem Dump das optimize Table läuft. Es ist deswegen eher zutreffend, dass dadurch diese Meldung zustande kommt, da optimzetble auf jeden Fall die Tabelle history sperrt und deswegen es ja auch wichtig ist DbLog im asynchronen Mode zu betreiben wenn man optimizetable ausführt. Darauf habe ich auch in der commandref hingewiesen.

Deswegen würde ich die reopen-Befehle in diesem Fall vorher/nachher einbauen um die Fehlermeldung zu vermeiden. Ungeachtet dessen gilt obiges, d.h. die Applikation kann auf diesen Zustand wie beschrieben reagieren.

LG,
Heiko

[pechnase]

Hallo Heike,

jetzt habe ich doch noch eine kleine Frage zu dem reopen vor dem Backup. Du schlägst als Zeit 1800 (sec) vor. Warum 30min., wenn das Backup so ca.220-250sec läuft. Wären da ein set DbLog reopen 500 nicht ausreichend.

LG Wolfgang

[DS_Starter]

Hallo Wolfgang,

du hast natürlich recht. Der Betrag ist nur so hoch gewählt, dass er garantiert (auch wenn die DB mal wächst o.ä.) die Backup-Zeit abdeckt.
Der Wert ist insofern nebensächlich, da das zweite reopen die DB sofort wieder öffnet, egal wie lange das erste reopen die DB geschlossen hat.
Man kann allerdings auch auf das zweite reopen verzichten und einfach nur die Zeit des "reopen xxx" abwarten.

Aber du hast den Zusammenhang schon absolut richtig dargestellt !

LG,
Heiko

[pechnase]

Hallo Heiko,

kurzes Feedback:
habe die reopen, wie von Dir vorgeschlagen, eingebaut. Nach einem manuellen und einem automatischen Backup heute Nacht kam keine Fehlermeldung mehr. Super.

Nochmals vielen Dank für die schnelle Hilfe.

Falls Du für das Modul noch weitere Leistungsmerkmale suchst, wäre ein gzip auf die Backups noch ein Wunsch. Die Files schrumpfen dann doch ziemlich stark. Hatte das mal mit executeAfterProc auch eingebaut, was auch funktioniert hat. Leider geht dann das 'Rollieren' der Backups wegen geändertem Filenamen nicht mehr. Gut, könnte man natürlich auch in einem Shell-Skript nachbilden.

LG Wolfgang

[DS_Starter]

Hallo Wolfgang,

freut mich dass es nun so läuft wie du es dir wünscht.
Dein Anregung bzgl. gzip nehme ich gerne auf und sehe mal zu in einem der nächsten Releases die Komprimierungsmöglichkeit mit vorzusehen. Es muss dann auch für die Versionierung und ebenfalls für einen Restore (vorher entkomprimieren) klappen. Aber das ist sicherlich zu bewerkstelligen.

Zur Zeit arbeite ich mit der Version 7.11.0 an einer Reparaturmöglichkeit für SQLite-Datenbanken. Es kommt ja immer mal wieder vor, dass die Meldung "database disk image is malformed" auf eine Korruption hinweist. Dann kann man als user ganz einfach einen Reparaturversuch mit DbRep starten.
Ich denke das Feature wäre für viele SQLite-Nutzer eine willkommene Hilfe.

Wenn ich soweit bin, veröffentliche ich die Version im DbRep-Thread zum Test.

LG,
Heiko

[DS_Starter]

Hallo Wolfgang,

habe soeben die V7.12.0 von DbRep eingecheckt.
Mit dem Attribut dumpCompress kannst man die Kompression der Dumpfiles einstellen. Restore von komprimierten Files ist direkt möglich.
Ab morgen früh im Update.

LG,
Heiko