Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

JoeALLb

Hallo Heiko,

hat funktioniert!
Das einzige, was mich etwas wundert(oder auch nicht!) ist dieser Eintrag imLog:

Das liegt sicher am "cacheLimit=302", aber ist es wirklich gut/hilfreich, hier mehrmals pro Sekunde während dem Backup
zu versuchen, einen Datensatz zu schreiben? Dies betrifft aber wohl eher DbLog.


2017.06.14 09:56:34 3: DbRep rep - Database dump finished successfully.
2017.06.14 09:56:34 4: DbRep rep -> BlockingCall DumpDone finished
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:54:19, Device: log, Event: CacheUsage: 304
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:54:19, Device: log, Event: CacheUsage: 306
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:54:19, Device: log, Event: CacheUsage: 308
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:14, Device: log, Event: CacheUsage: 314
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:14, Device: log, Event: CacheUsage: 316
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:18, Device: log, Event: CacheUsage: 320
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:18, Device: log, Event: CacheUsage: 322
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:18, Device: log, Event: CacheUsage: 324
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 328
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 330
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 332
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 334
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:20, Device: log, Event: CacheUsage: 338
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:22, Device: log, Event: CacheUsage: 344
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:22, Device: log, Event: CacheUsage: 346
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:22, Device: log, Event: CacheUsage: 348
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 352
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 354
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 356
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 358
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 362
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 364
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 366
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 368
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:20, Device: log, Event: CacheUsage: 372
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:21, Device: log, Event: CacheUsage: 376
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#451
Hi Joe,

Naja DbLog macht halt das was du ihm gesagt hast, nämlich bei Überschreitung von cacheLimit versuchen wegzuschreiben. Das erfolgt eventgesteuert, nicht zeitgesteuert.

Ich würde DbLog im produktiven Betrieb mit verbose 2 betreiben, dann kommen nur die "echten" Probleme hoch.

Dann werde ich das neue DbRep mal einchecken ...

Edit: du kannst auch mit executeBefore / executeAfter das Attribut cacheLimit vom DbLog-Device während des Backup abändern.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

JoeALLb

Zitat von: DS_Starter am 14 Juni 2017, 12:43:31
Naja DbLog macht halt das was du ihm gesagt hast,...
Darum so vorsichtig formuliert... es ging mir mehr um die Sinnhaftigkeit... ;-)

Zitat von: DS_Starter am 14 Juni 2017, 12:43:31
Edit: du kannst auch mit executeBefore / executeAfter das Attribut cacheLimit vom DbLog-Device während des Backup abändern.
Korrekt!Mir schwebt aber eine globale Info über "db temporär nicht verfügbar" vor, sei es als Reading oder als globale Variable,
denn darauf würde ich zB gerne auch im Plot-Modul oder anderen Modulen reagieren.
Wennd ie DB gerade blockiert wird, macht das ewige Warten auf Plots einfach keinen Sinn, und selbst wenn man in FHEM in einen Raum ohne Plots wechselt,
bleibt der FHEM-Server blockiert oder zumindest stark ausgelastet...
Aber das ist, wie oben gesagt, eher ein Thema für den DbLog-Thread.....
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

So ein Reading kannst du dir über die Nutzung der userExitFn erstellen. Hier kann man z.B. verschiedene Status des DbRep und/oder DbLog-Device verknüpfen um sich ein "Tabelle ist geblockt" Status abzuleiten und als Reading zu setzen.
Nur Mal als Idee ohne es genau durchdacht zu haben ..,
Können wir in dem anderen Thread Mal diskutieren.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo zusammen,

im ersten Beitrag habe ich die V5.3.0 hinterlegt.
Für MySQL kann "optimizeTable" als separater Befehl ausgeführt werden. Das verbundene DbLog-Device sollte im asynchronen Modus betrieben werden um FHEM nicht zu blockieren.

VG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Mit der V5.3.1 gibt es nun ebenfalls für SQLite und PostgreSQL die Möglichkeit die Datenbank zu optimieren (vacuum).
Auch in diesem Fall muß das verbundene DbLog-Device im asynchronen Modus betrieben werden um FHEM nicht zu blockieren.
Die Commandref ist ergänzt.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

In der Version 5.4.0 kann ein Restore (restoreMySQL) einer mit "dumpMySQL serverSide" erstellten Sicherung durchgeführt werden.
Die Funktion enthält eine Dropdown-Liste, welche die gefundenen Dateien im Verzeichnis gegeben durch Attribut "dumpDirLocal" enthält. Es werden nur die Dumpdateien der "eigenen" verbundenen Datenbank (Internal DATABASE) angezeigt.
Das Attribut  "dumpDirLocal" muß in diesem Fall das gemountete Verzeichnis des MySQL/MariaDB-Servers enthalten in dem die Dumps erstellt werden.
Es entspricht den empfohlenen Einstellungen für "dumpMySQL serverSide".

Das verwendete Verfahren ist sehr schnell. Bei meinen Versuchen wurde die DB (nur Tabelle history) mit ca. 2,8 Mio Datensätzen in 14s exportiert und innerhalb von 136s wieder importiert.


2017.07.03 21:00:34.894 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:00:34.895 3: DbRep Rep.LogDB1 - ###             New database serverSide dump                 ###
2017.07.03 21:00:34.895 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:00:34.907 3: DbRep Rep.LogDB1 - Searching for tables inside database fhemtest1....
2017.07.03 21:00:34.950 3: DbRep Rep.LogDB1 - Starting dump of database 'fhemtest1', table 'history'.
2017.07.03 21:00:48.957 3: DbRep Rep.LogDB1 - Finished backup of database fhemtest1, total time used: 14 sec.
2017.07.03 21:00:48.957 3: DbRep Rep.LogDB1 - Size of backupfile: 305.54 MB
2017.07.03 21:00:48.961 3: DbRep Rep.LogDB1 - Deleting old dumpfile 'fhemtest1_history_2017_07_03_20_37.csv'
2017.07.03 21:00:48.973 3: DbRep Rep.LogDB1 - Database dump finished successfully.
2017.07.03 21:02:36.595 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:02:36.596 3: DbRep Rep.LogDB1 - ###             New database Restore/Recovery                ###
2017.07.03 21:02:36.596 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:02:36.607 3: DbRep Rep.LogDB1 - Starting restore of database 'fhemtest1', table 'history'.
2017.07.03 21:04:52.136 3: DbRep Rep.LogDB1 - Restore of /volume1/ApplicationBackup/dumps_FHEM/fhemtest1_history_2017_07_03_21_00.csv into 'fhemtest1', 'history' finished - total time used: 136 sec.
2017.07.03 21:04:52.151 3: DbRep Rep.LogDB1 - Database restore finished successfully.


Funktion ist für MySQL verfügbar.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo,

ich checke nachher die Version 5.5.0 ein.

Damit ist dann "restoreMySQL" im Repository verfügbar.

ACHTUNG: In DbLog wurde das Internal "MODEL" eingeführt. DbRep habe ich auf dieses Internal umgestellt. Falls nach dem Update von DbRep Fehler auftreten sollten bitte danach schauen dass auch DbLog aktuell ist (V 2.18.3).

VG
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo zusammen,

es gibt in der Version 5.6.1 für MySQL die Möglichkeit sich die Datenbankprozesse ausgeben zu lassen:

* '''procinfo''' : listet die existierenden Datenbank-Prozesse in einer Tabelle auf (nur MySQL).
Typischerweise werden nur die Prozesse des Verbindungsusers (angegeben in DbLog-Konfiguration) ausgegeben. Sollen alle Prozesse angezeigt werden, ist dem User das globale Recht "PROCESS" einzuräumen.
Für bestimmte SQL-Statements wird seit MariaDB 5.3 ein Fortschrittsreporting (Spalte "PROGRESS") ausgegeben. Zum Beispiel kann der Abarbeitungsgrad bei der Indexerstellung verfolgt werden.
Weitere Informationen sind hier https://mariadb.com/kb/en/mariadb/show-processlist/ verfügbar.

Auch habe ich festgestellt, dass der empfohlene zusätzliche DbRep-Index bei großen Datenbanken insbesondere bei Sortierungsvorgängen nicht hilfreich ist und habe ihn entsprechend angepasst. Es ist besser ihn so anzulegen:


CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;


Bitte ersetzt den alten Reading_Time_Idx sofern ihr diesen bei euch angelegt haben solltet.
In DbLog habe ich den configCheck ab Version 2.21.1 ebenfalls auf diesen neuen Index angepasst.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Omega

Hallo Heiko,

wäre es bei Gelegenheit möglich, beim attr device auch <devspec> zu verwenden?

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

DS_Starter

#460
Zitatwäre es bei Gelegenheit möglich, beim attr device auch <devspec> zu verwenden?
Ich habe "befürchtet" dass früher oder später diese Frage kommt. Es wunderte mich nur dass sie solange auf sich hat warten lassen  ;)

Grundsätzlich sollte es möglich sein, allerdings habe ich bislang den Aufwand gescheut jede Funktion wieder anzufassen, umzubauen und auf ihre Funktion zu testen.
Aber ich versuche mal daran zu denken wenn die Tage wieder länger kürzer  ??? und das Wetter mieser wird....

LG
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Omega

Danke für's "auf dem Schirm haben" - eilt ja wirklich nicht. Je mehr schöne Funktionen man in FHEM entdecken kann, desto öfter möchte man die dann überall haben  ;D

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

Thyraz

Vielen Dank mal wieder für das Modul. :)

Bin wegen Charting mit Grafana (welches jetzt ja auch MySQL als Datenquelle erlaubt, womit man sich die zusätzliche InfluxDB sparen kann) von einer lokalen SQLite3 Datenbank auf MySQL (oder genauer gesagt MariaDB auf meiner Synology) umgestiegen.

Seit wir DBLog mit dem Async-Betrieb haben, ist ein kurzes Verschwinden der DBLog Verbindung (z.B. Restart NAS, oder Update MariaDB auf dem NAS) für FHEM ja kein Problem mehr.
Und dank Caching der Events verliert man ja nichtmal mehr Logevents, da die gecachten Ereignisse beim Wiederkehren der DB-Verbindung brav nachgetragen werden.

Mit aktuellem DBLog und DBRep bereitet Fhem in Verbindung mit einer Datenbank richtig Freude. ;)

Hab zum Umzug von SQLite3 in eine MySQL Datenbank einfach die Hinweise hier befolgt:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Datens.C3.A4tze_.28Devices.29_von_einer_Datenbank_in_eine_andere_umziehen_.28Export.2FImport.29
Allerdings eben das Attribut device im DBRep nicht gesetzt, so dass alle Datenbankeinträge gesichert (und danach wiederhergestellt) wurden.

Hat durch die große DB doch ein wenig gedauert bis er das alles durchgenudelt hatte, aber am Ende waren alle Einträge wieder in der neuen Datenbank vorhanden. :)
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

DS_Starter

Hallo Thyraz,

vielen Dank für diesen Erfahrungsbericht und mich freut natürlich dass dein Vorhaben so gut mit den Werkzeugen funktioniert hat  :)

Ich muss zugeben dass die enge Verschmelzung von DbLog und DbRep mein Ziel war und dass man quasi ein Set an Werkzeugen hat um mit einer DB in FHEM möglichst reibungsfrei zu arbeiten.
Bin natürlich bemüht diesen "Werkeugkasten" stetig zu verbessern und zu erweitern.

Rudi hat ja aktuell die Blocking.pm erweitert. DbLog und DbRep habe ich angepasst damit die Abbruchfunktion (früher nur Timeout) nun auch die erweiterte Ausgabe von Blocking ausgibt.

Die Version 5.6.4 von DbRep habe ich wie gehabt im ersten Beitrag hinterlegt.

LG
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Guten Abend,

es gibt im ersten Beitrag die Version 5.8.0.

Neben kleinen Fixes gibt es nun für die Funktionen countEntries und fetchrows die Möglichkeit entweder die Tabelle history oder current auszuwählen.
Damit kann man sich auch schnell einmal einen Überblick darüber verschaffen welchen Inhalt die current zur Zeit hat.

Die Version checke ich heute Abend auch noch ein.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter