DBLog / MariaDB: Werte aus bisheriger Datenbank in neue Datenbank übernehmen

Begonnen von Thyraz, 04 Juni 2018, 09:23:54

Vorheriges Thema - Nächstes Thema

Thyraz

Hallo zusammen. :)

Habe gestern wegen besserer Performance MariaDB von meiner Synology auf den NUC umgezogen.
Hatte einen Dump von der "fhem" Database auf der Synology gemacht und dann auf dem NUC importiert.
Die Daten sahen in phpMyAdmin dann auch einwandfrei aus, ich sehe alle alten Logeinträge.

FHEM konnte auch zur DB auf dem NUC connecten, hat aber beim Versuch zu loggen Fehler geworfen:
Zitat
DbLog DbLog -> Error table history - DBD::mysql::st execute_array failed: executing <fortlaufende Nummer> generated 2 errors at ./FHEM/93_DbLog.pm line 2050.

Da ich gestern Abend keine Zeit mehr hatte das genauer zu untersuchen und ich die Events im Cache von DBLog nicht verlieren wollte,
habe ich kurzerhand die Database "fhem" in MariaDB in "fhem_old" umbenannt und eine neue Database "fhem" nach den Empfehlungen im Wiki angelegt.

Als ich die DB Verbindung in DBLog wieder geöffnet habe, wurden alle gecachten Einträge problemlos geloggt und seitdem läuft das Ganze einwandfrei.

Meine Frage ist jetzt: Wie bekomme ich die Einträge aus der history table in "fhem_old" in die neue Database kopiert?
Die ganze Datenbank per mysqldump exportieren wie ich es normal zum Backup mache ergibt wahrscheinlich wenig Sinn.
"fhem" existiert ja schon mit den neueren Logeinträgen.

Bekommt man das dann mit einem SQL Kommando hin, oder geht man doch über ein Dump-File?
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

Eine Möglichkeit ist folgende.
Lege dir eine dblog an was auf deine history-old zeigt und definiere ein DbRep was das neue dblog verwendet. Achte darauf dass das dblog nichts loggt - entspr. Regex im DeF setzen.

Dann kannst du die Daten per export/import übertragen wie im wiki 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 beschrieben, oder du verwendest die relativ neue Funktion syncStandby im DbRep.
Dann läuft die Übertragung im Hintergrund ab bis alles in der neuen DB ist.

Grüße
Heiko
Proxmox+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

Thyraz

Danke. :)

Sehr coole Lösung, hat einwandfrei funktioniert.
Denke mal, das ist allgemein kein schlechter Weg, da es die Daten nochmal loggt wie es Fhem immer macht, richtig?

Sprich selbst wenn die alte DB irgendwie falsch konfiguriert gewesen wäre,
könnte man das so wieder in eine "gute" DB umziehen, solange DBRep aus der alten DB Device/Reading/Timestamp/... noch korrekt lesen kann, oder?
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

Ich nehme an du sprichst gerade von der syncStandby-Variante.
Ja im Prinzip kann man über diesen Weg seine Db reorganisieren und auch von doppelten Datensätzen befreien wenn man in der Ziel-Db einen primary Key setzt. Oder auch nicht mehr gewünschte Devices/Readings vom Umzug ausnehmen indem man im DbRep die Attribute device und reading vor der Übertragung entsprechend setzt.
Es gibt da bestimmt viele Spielarten mit diesem Werkzeug zumal man auch den Typ der DB ändern kann ... also zB von SQLite nach MySQL/MariaDb umziehen  :)

Also alle deine Fragen wären mit Ja zu beantworten.
Proxmox+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

Thyraz

Ok, irgendwas ging doch noch schief.
Sieht aus als ob das Ganze doppelt ausgeführt wurde.

Gerade gewundert, dass mit in phpMyAdmin etwa 17 Millionen Einträge in der Datenbank angezeigt werden.
Beim Import meinte DBRep es hätte etwa 8.5 Millionen importiert und davor waren nur ein paar Tausend Einträge seit gestern Abend drin.

Hab dann die Records angeschaut und es scheint alles doppelt importiert worden zu sein.
Habe nicht den Weg mit syncStandby gewählt sondern mit exportToFile/importFromFile.

Werde ich die Doubletten irgenwie wieder elegant los?
Identifizierbar sind sie ja anhand identischen Werten in TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT...

Sonst lösch ich nochmal alles raus was älter als der Neuanfang von gestern ist und versuche den Import nochmal neu.
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

Schau dir mal die Exportfiles an. Ich persönlich habe noch nicht erlebt dass etwas doppelt importiert wurde . Kann mir nicht vorstellen wie das passieren könnte. Die Datei wird einfach ausgelesen. Probiere ich heute Abend auch nochmal bei mir.
Also mit DelSeqDoublets im DbRep solltest du die Doubletten wieder loswerden können.
Proxmox+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

Thyraz

Danke die Idee delSeqDoublets dafür zu nutzen ist gut. :)

Er hat bei mir allerdings nur 8 Einträge gelöscht, welche wirklich in das Schema von aufeinanderfolgenden gleichen Werten passen.
Meine importierten Doubletten, welche den selben Zeitstempel haben sind weiterhin da.
Kann es sein, dass delSeqDoublets da doch nicht greift wenn nicht wenigstens eine Sekunde Unterschied dazwischen ist?

Oder habe ich noch ein zeitliches Limit?
Habe keine Attribute außer allowDeletion gesetzt, was mir laut Comandref so in Ordnung vorkommt.
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

Zitat
Kann es sein, dass delSeqDoublets da doch nicht greift wenn nicht wenigstens eine Sekunde Unterschied dazwischen i

War natürlich zu kurz von mir gedacht. Die Timestamps sind es nicht, aber die Funktion lässt die Datensätze stehen wenn vor und nach der Doublette Wertewechsel vorkommen. It's not a bug, it's a feature  ;)
Das dürfte bei dir der Fall sein.

Am einfachsten ist es eine neu (mal wieder) Datenbank anzulegen und dort einen primary Key auf die History zu legen.


ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);


Dann exportierst du alle Sätze deiner jetzigen produktiven DB wie gehabt mit DbRep und setzt dir dabei das Attr "timestamp_end" auf die aktuelle Zeit.
Den Export importierts du in die neue DB mit dem PK ... damit fliegen automatische alle Doubletten raus.
Jetzt kannst du überlegen ob du die Daten in der produktiven löschst und wieder dort bereinigt importierst oder die neue mit dem PK als produktive einsetzt und die restlichen Sätze aus der alten produktiven noch übernimmst ...

Ich teste mal inzwischen bei mir wegen dem doppelten Import. Kommt mir komisch vor.

Proxmox+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

Thyraz

Hab es doch noch mit DBRep hinbekommen. ;)

delEntries mit Datum/Zeit an dem ich die neu DB angefangen habe.
Dann hatte ich wieder den Zustand wie vor dem importFromFile.

Danach hab ich den Import nochmal laufen lassen, da das Export File von den Einträgen her gut aussah.
Ist soeben fertig durchgelaufen und diesmal sind keine Doubletten da. :)

Keine Ahnung was da beim ersten Mal schief lief...
Aus versehen zweimal ausgeführt haben kann ich das ja kaum bei einer Laufzeit von über 15 Minuten pro Import bei der Datenmenge.  ;D

Danke dir auf alle Fälle für deine umfassende Hilfe und mit DbRep kenn ich mich jetzt auch wieder ein wenig mehr aus.
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

Super  :)

Dann kann ich mich wieder mit neuen Dingen beschäftigen  8)
Es gibt wie immer unterschiedliche Wege, das ist ja das spannende. Wenn du Spaß daran hast versuche auch mal die syncStandby-Funktion. Eine integrative Lösung die auch nicht schlecht ist.

Proxmox+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

Thyraz

Hab noch eine Frage nachdem du mich auf delSeqDoublets gebracht hast:
Ich hab da eben seqDoubletsVariance entdeckt.

Überlege schon länger wie ich am Besten die vielen historischen Temperaturwerte der Lacrosse Sensoren ausdünne.

Wie läuft das denn intern genau ab, wenn ich nun meine Device-Spec und das temperature Reading mit seqDoubletsVariance 0.5 kombiniere?

Das Problem bei Lacrosse ist ja oft der Wechsel wenn eine Temperatur ziemlich mittig z.B. zwischen 21.4°C und 21.5°C liegt. Dann kann es sein, dass man alle 5 Sekunden ein hin- und herwechseln hat.

Das häufige Senden führt aber auch dazu, dass man selten größere Sprünge als 0.1°C hat, auch wenn in recht kurzer Zeit eine größere Temperaturänderung stattfindet. Man hat dann halt recht viele 0.1°C Sprünge in sehr kurzer Zeit.

Greift seqDoubletsVariance hier dennoch?
Also vergleicht es jeden Folgewert mit dem zuletzt im Log belassenen Wert, oder braucht es einen größeren Sprung (als in seqDoubletsVariance angegeben) zwischen zwei aufeinanderfolgenden Werten?

edit: Und was für ein Wert wird dann als neuer Wert geloggt? Der tatsächliche Wert der als erster eine Änderung von seqDoubletsVariance überschritten hat, oder rundest du dann irgendwie um durch seqDoubletsVariance teilbare Werte zu loggen.
Die erste Variante, also den tatsächlichen Wert des Events zu loggen wäre für mich sinnvoller denke ich.
So ist bei einem erneuten Hin- und Herspringen der Temperatur dann erstmal wieder Ruhe in der Datenbank bis eine größere Änderung stattfindet.

Sorry für das nachbohren, aber bei solchen Funktionen kommt oft Unerwartetes heraus, wenn man das Verhalten nicht genau kennt. ;)
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

Es ist so dass seqDoubletsVariance die positive oder negative Abweichung zwischen zwei direkt aufeinanderfolgenden Werten beschreibt die als gleich angesehen werden und dann der Datensatz gelöscht wird.
Beispiel:


DS1 11,0
DS2 11,1
DS3 10,8
DS4 12,0
DS5 12,2
...


Es wird immer der Vorgänger mit dem Nachfolger verglichen. Bei seqDoubletsVariance  = 0,5 würde folgendes passieren:
DS1 wird mit DS2 verglichen -> seqDoubletsVariance  ist erfüllt (Diff = 0,1 < 0,5) und DS2 wird gelöscht. DS1 bleibt erhalten.
Dann wird DS1 mit DS3 erglichen -> seqDoubletsVariance  ist erfüllt (Diff = 0,2 < 0,5) -> DS3 wird gelöscht, DS1 bleibt.
DS1 wird mit DS4 verglichen -> seqDoubletsVariance  ist nicht erfüllt (Diff = 1 > 0,5) -> DS1 und DS4 bleiben.
DS4 wird  mit DS5 verglichen und das Spiel setzt sich fort.

Zitat
edit: Und was für ein Wert wird dann als neuer Wert geloggt?
Also mit Logging hat das Ganze nichts zu tun. Geloggt wird ja alles was kommt und DbLog loggen soll.
Mit dieser DbRep-Funktion geht es ja nur um eine nachträgliche Bereinigung der DB.

Proxmox+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

Thyraz

Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Thyraz

Also in Verbindung mit den LaCrosse Thermometern ist das echt genial.

Wie gesagt springen die einem Temperaturwechsel in eine bestimmte Richtung immer unzählige Male hin und her bis der neue Wert stabil bleibt.
Wenn man Event-On-Change-Reading verwendet hat man somit weit mehr sinnfreie Einträge in der DB als sinnvolle.
Es gibt aber auch keine einfachen Mechanismen in FHEM um das direkt rauszufiltern, da man dazu mehr als nur den alten und neuen Wert beim Wechsel betrachten muss.

Denke ich werde daher einfach ein DBRep Device automatisiert einmal im Monat laufen lassen.
seqDoubletsVariance hab ich jetzt auf 0.2

Damit sind bei mir nur von Temperatur Einträgen vom letzten Jahr über 3 Millionen Einträge aus der DB gefolgen.
Verblieben sind nur noch etwa 100.000 Einträge.
Und das Ganze ohne sichtbare Veränderungen in den Plots. :)
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...