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
Wie groß ich CacheUsage ?
Grüße,
Heiko
Zur Zeit 4033.
Allerdings hatte ich zwischendurch FHEM neu gestartet, da der Cache Usage bei 90000 lag.
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.
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
Ggf. mehrfach ausführen...
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.
Und setze dir zusätzlich noch das Attr commitMode = basic_ta:off
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.
Dann starte jetzt mit diesen Attribnuten dein FHEM neu.
Bis jetzt läuft es.
Ich werde es weiter beobachten, ob es so auch bleibt.
Auf jeden Fall danke.
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
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.
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
Nein das muss nicht geloggt werden.
Als ich das gesehen hatte, aber ich sofort den Spaß excluded. ;D
War einfach beim erstellen durchgerutscht.