Hallo zusammen,
vermutlich ist configDB nicht schuld, aber ich weiß nicht mehr weiter, wo ich noch analysieren soll.
Mein Aufbau sieht wie folgt aus: ich habe einen NUC, auf welchem zwei FHEM-Instanzen (historisch gewachsen) im Docker laufen. Beide speichern ihre Konfiguration mit configDB. Hierfür habe ich einen MySQL 5.7-Docker-Container für beide Instanzen, aber mit verschiedenen Datenbanken. Bis vor kurzem hatte ich folgende Situation: wenn ich in Instanz 2 auf speichern drücke, wird das Speichern nach 1-2 Sekunden mit der Meldung "configDB saved" bestätigt. In Instanz 1 erschien nach dem Betätigen des Speichern-Befehls die Meldung "Connection lost, trying a reconnect..." und nach ca. 30-40 Sekunden war das Speichern abgeschlossen - innerhalb dieser Zeit war FHEM nicht "funktionsfähig" (Freezemon meldet einen Freeze). Dieses Verhalten hatte ich auch schon, bevor ich beide Instanzen in einen gemeinsamen Mysql-Container umgezogen habe. Da mein FHEM relativ umfangreich ist, habe ich diese Verzögerung darauf geschoben:
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 22995 2020-10-20 09:10:09Z betateilchen $
c:$Id: 98_configdb.pm 22340 2020-07-03 11:01:06Z betateilchen $
-----------------------------------------------------------------
dbconn: mysql:database=configDB_fhem;host=configDB;port=3306
dbtype: MYSQL
-----------------------------------------------------------------
max Versions: 50
lastReorg: Mon Nov 23 20:22:41 2020
config: 133981 entries
Ver 0 saved: Mon Nov 23 20:22:38 2020 def: 886 attr: 4926
Ver 1 saved: Mon Nov 23 18:29:38 2020 def: 886 attr: 4926
Ver 2 saved: Mon Nov 23 18:16:47 2020 def: 886 attr: 4926
Ver 3 saved: Mon Nov 23 17:28:25 2020 def: 886 attr: 4926
Ver 4 saved: Mon Nov 23 16:37:14 2020 def: 886 attr: 4926
Ver 5 saved: Sun Nov 22 22:21:52 2020 def: 886 attr: 4926
Ver 6 saved: Sun Nov 22 22:19:33 2020 def: 886 attr: 4926
Ver 7 saved: Sun Nov 22 22:14:32 2020 def: 886 attr: 4926
Ver 8 saved: Sun Nov 22 22:12:48 2020 def: 886 attr: 4926
Ver 9 saved: Sun Nov 22 21:58:18 2020 def: 886 attr: 4926
Ver 10 saved: Sun Nov 22 21:55:16 2020 def: 886 attr: 4926
Ver 11 saved: Sun Nov 22 21:44:49 2020 def: 886 attr: 4926
Ver 12 saved: Sun Nov 22 21:28:54 2020 def: 886 attr: 4926
Ver 13 saved: Sun Nov 22 21:06:14 2020 def: 886 attr: 4926
Ver 14 saved: Wed Nov 18 10:23:53 2020 def: 886 attr: 4927
Ver 15 saved: Thu Nov 12 21:24:33 2020 def: 886 attr: 4926
Ver 16 saved: Sat Nov 7 22:05:02 2020 def: 886 attr: 4926
Ver 17 saved: Sat Nov 7 21:59:25 2020 def: 886 attr: 4926
Ver 18 saved: Tue Nov 3 22:03:23 2020 def: 886 attr: 4926
Ver 19 saved: Tue Nov 3 21:57:27 2020 def: 886 attr: 4926
-----------------------------------------------------------------
state: 7190 entries saved: Mon Nov 23 20:22:38 2020
-----------------------------------------------------------------
filesave: 12 files stored in database
-----------------------------------------------------------------
Nun habe ich seit ein paar Tagen (ich kann nicht mal genau sagen, seit wann) das riesen Problem, dass keine Änderungen in Instanz 1 mehr gespeichert werden: wenn ich Speichern betätige, erhalte ich "wie gewohnt" die "Connection lost"-Meldung, aber nach Wiederverbinden sind alle Änderungen verschwunden. Scheinbar können noch alle Daten aus der Datenbank gelesen, aber keine Änderungen mehr geschrieben werden. Instanz 2 funktioniert diesbezüglich ganz normal.
Wo kann ich noch angreifen, um der Ursache auf die Spur zu kommen?
Vielen Dank
Ronny
Was genau heisst "speichern"?
"Save config" oben links, oder fhem.cfg editieren, und dann "Save fhem.cfg".
Ersteres sollte nicht in "Connection lost" enden und sollte wenige ms dauern.
Die zweite Alternative ist _deutlich_ aufwendiger.
Und was steht in FHEM-Log?
Zitat von: rudolfkoenig am 23 November 2020, 20:45:16
"Save config"
ja
Zitat von: rudolfkoenig am 23 November 2020, 20:45:16
Und was steht in FHEM-Log?
Vermutlich die Ursache:
PERL WARNING: DBD::mysql::st execute failed: Data too long for column 'P2' at row 1 at configDB.pm line 736. :-\
Und nun habe ich scheinbar auch die Ursache gefunden: das Attribut "styleData" der FHEMWEB-Instanz vom flexStyle hat über 66000 Zeichen...
Edit:
Attribut gelöscht und siehe da, es geht wieder :-D
Zitat von: rudolfkoenig am 23 November 2020, 20:45:16
oder fhem.cfg editieren, und dann "Save fhem.cfg".
Rudi, das dürfte bei einem configDB Anwender wenig Relevanz besitzen.
Zitat von: RoBra81 am 23 November 2020, 20:53:12
PERL WARNING: DBD::mysql::st execute failed: Data too long for column 'P2' at row 1 at configDB.pm line 736.
P2 ist vom Typ "TEXT" und da passen 64 Kilobyte Daten rein.
Das Feld wird nur bei define und attr benutzt.
Schreibst Du einen Roman in ein Attribut?
hat sich irgendwie überschnitten.
Da flexStyle z.Zt. verwaist ist, bleibt nichts Anderes uebrig, als die Spalte umzubauen, mediumtext duerfte reichen.
@betateilchen: im ersten Beitrag stand nichts darueber, dass mit fhem.cfg keine Probleme gibt :)
Zitat von: rudolfkoenig am 23 November 2020, 22:56:35
@betateilchen: im ersten Beitrag stand nichts darueber, dass mit fhem.cfg keine Probleme gibt :)
configDB steht aber schon im Thread-Titel :)
In allen Threads, in denen es um Probleme in/mit fhem.cfg geht, erwartest Du schließlich auch nicht, dass der Anwender auch testet, ob es mit configDB funktionieren würde...
Zitat von: rudolfkoenig am 23 November 2020, 22:56:35
Da flexStyle z.Zt. verwaist ist, bleibt nichts Anderes uebrig, als die Spalte umzubauen,
Das werde ich nicht tun. Ein Attribut mit mehr als 64kB Inhalt macht wenig Sinn, das kann man für einen Style sicher entwicklungsseitig auch anders/besser lösen.