Hauptmenü

Dblog Sync error

Begonnen von Mirko_2013, 05 Juli 2020, 20:53:14

Vorheriges Thema - Nächstes Thema

Mirko_2013

Hallo zusammen,

Ich hoffe Ihr könnt mir helfen.
Über Nacht ohne Update funktioniert die DB Verbindung via DBLog nicht mehr.
Ich habe keine Idee in welche Richtung ich suchen muss.
Evtl. könnt Ihr mir helfen.

Fehlermeldung:

DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 2456

Commit already running - resync at NextSync



DB Config Check:


Result of version check

Used Perl version: 5.26.1
Used DBI (Database independent interface) version: 1.64
Used DBD (Database driver) version mysql: 4.046
Used DbLog version: 4.10.0.
A new DbLog version is available (creation time: 2020-06-24_07:45:03, size: 443191 bytes)
Recommendation: You should update FHEM to get the recent DbLog version from repository ! Your DBD version fulfills UTF8 support, no need to update DBD.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=10.4.0.120;port=3306, User -> fhemuser, Password -> read o.k.

Result of connection check

Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k. Your DBD version fulfills UTF8 support, no need to update DBD.

Result of logmode check

Logmode of DbLog-device myDbLog is: asynchronous
Recommendation: settings o.k.

Result of insert mode check

Insert mode of DbLog-device myDbLog is: Bulk
Recommendation: settings o.k.

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.

EL.apiWEB: plotfork=0 / plotEmbed=0
WEB: plotfork=0 / plotEmbed=0
WEBphone: plotfork=0 / plotEmbed=0
WEBtablet: plotfork=0 / plotEmbed=0
apiWEB: plotfork=0 / plotEmbed=0

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".


Result of table 'history' check

Column width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in DB current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

No DbRep-device assigned to myDbLog is used. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.



Gruß
Mirko
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB

DS_Starter

Wie groß ich CacheUsage ?

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

Mirko_2013

Zur Zeit 4033.
Allerdings hatte ich zwischendurch FHEM neu gestartet, da der Cache Usage bei 90000 lag.
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB

DS_Starter

Ja, schade.

Da war etwas im Cache was der DB nicht gefallen hat. Das Problem scheint noch vorhanden zu sein, weil der Cache nicht gespeichert wird,
Leere ihn mit

set <> exportCache purgeCache

Danach sollte alles normal laufen.
Das geschriebene Cachefile muss man sich dann anschauen ob etwas auffälliges zu sehen ist.
Typisch ist dieser MySQL Fehler wenn die zu schriebende Datenmenge die eingestellte Servervariable max_allowed_packet übersteigt.
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

Mirko_2013

#4
Ich habe den Cache geleert.
Innerhalb von wenigen Minuten, ist der Cache wieder bei über 2000 Einträgen.
Selbst nach dem purge stand der Status noch auf ,, Commit already running - resync at NextSync".
Verbose habe ich auf Level 4 gestellt.

Wonach müsste ich wie suchen um herauszufinden wo das Problem liegt.
Der Status war wieder :

DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 2456.


Gruß
Mirko
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB

DS_Starter

Ggf. mehrfach ausführen...
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

ZitatWonach müsste ich wie suchen um herauszufinden wo das Problem liegt.
Kann ich pauschal nicht beantworten. Große Datenmengen bzw. Nicht ASCII Zeichen zum Beispiel

Stelle dir noch das DbLog Attribut useCharfilter = 1 ein.
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

Und setze dir zusätzlich noch das Attr  commitMode = basic_ta:off
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

Mirko_2013

Meine Einstellungen ( Attribute) sind:

attr myDbLog DbLogType Current/History
attr myDbLog asyncMode 1
attr myDbLog bulkInsert 1
attr myDbLog disable 0
attr myDbLog room Konfiguration
attr myDbLog useCharfilter 1
attr myDbLog userReadings DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }

Neu gesetzt:
attr myDbLog verbose 4
attr myDbLog commitMode basic_ta:on

Trotz mehrmals löschen des Cache ändert sich der Status nicht.
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB

DS_Starter

Dann starte jetzt mit diesen Attribnuten dein FHEM neu.
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

Mirko_2013

Bis jetzt läuft es.
Ich werde es weiter beobachten, ob es so auch bleibt.

Auf jeden Fall danke.
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB

DS_Starter

Grad noch was gesehen. Du hast

attr myDbLog commitMode basic_ta:on

eingestellt. Solltest aber

attr myDbLog commitMode basic_ta:off

setzen. Jetzt aber nicht mehr ändern, nur im Fehlerfall !

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

Mirko_2013

Heute Morgen gab es wieder Probleme.
Irgendwie scheint es Probleme mit Message Befehlen zu geben.
Ich lasse mir jeden Morgen aufs Handy Staumeldugen schicken, was scheinbar zu Problemen führt.



DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'A4_Stauinfo' device=notify07 'Es liegen um 05:40 fuer die A','Einfahrt Neudieten' at line 1 at ./FHEM/93_DbLog.pm line 2456.
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB

DS_Starter

Um das zu analysieren bzw. zu beheben braucht man den gesamten Event der geloggt werden soll.

Aber mal Hand aufs Herz, muss man so etwas wirklich loggen ?

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

Mirko_2013

Nein das muss nicht geloggt  werden.
Als ich das gesehen hatte, aber ich sofort den Spaß excluded.  ;D
War einfach beim erstellen durchgerutscht.
HP Microserver Gen8; fhem-5.8; CUL868 - V1.66; CUL868 - V1.61; CUL433 - V1.61; CUNX - V2.67; eBus Koppler USB