[gelöst]configdb + mysql weiterhin keine state Infos mehr nach Neustart

[persching]

Du hast doch Docker?
Also Container runterfahren, neues Verzeichnis mit neuen Container und den dann hochfahren. Wieso dann ein Komplett neues System?

Stimmt, irgendwie hatte ich daran nicht gedacht. Dann ist nur noch das Problem, dass ich dann eine leere Config habe...

Stimmt Deine Datenbank, also die Definition der Tabbelen, mit den gewünschten von config db überein?

...darum werde ich erstmal diesen Punkt prüfen.

[persching]

Heute habe ich mich mal wieder an die Fehlersuche gemacht, und ich vermute, ich habe was gefunden. Die Datei init.sql, die mir ja die Datenbank beim Erstellen des Containers initialisiert, hat folgende Einträge:

Code: [Auswählen]

CREATE DATABASE `fhem` DEFAULT CHARACTER SET = `utf8`;

CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'ltuajsdflkssjaskdas';

REVOKE CREATE ROUTINE, CREATE VIEW, CREATE USER, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, SUPER, >

UPDATE mysql.user SET max_questions = 0, max_updates = 0, max_connections = 0 WHERE User = 'fhemuser' AN>

GRANT CREATE ROUTINE, CREATE VIEW, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, INSERT, SELECT, DELET>

USE `fhem`;

CREATE TABLE history (
    TIMESTAMP TIMESTAMP,
    DEVICE varchar(64),
    TYPE varchar(64),
    EVENT varchar(512),
    READING varchar(64),
    VALUE varchar(255),
    UNIT varchar(32),
    KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`,`VALUE`),
    KEY `Device_Idx` (`DEVICE`,`READING`),
    KEY `Report_Idx` (`TIMESTAMP`,`READING`) USING BTREE
);

CREATE TABLE current (
    TIMESTAMP TIMESTAMP,
    DEVICE varchar(64),
    TYPE varchar(64),
    EVENT varchar(512),
    READING varchar(64),
    VALUE varchar(255),
    UNIT varchar(32)
);

CREATE TABLE fhemversions (
        `VERSION`       INT,
        `VERSIONUUID`   CHAR ( 50 )
);
CREATE TABLE fhemstate (
        `stateString`   TEXT
);
CREATE TABLE fhemconfig (
        `COMMAND`       VARCHAR ( 32 ),
        `DEVICE`        VARCHAR ( 64 ),
        `P1`    VARCHAR ( 50 ),
        `P2`    TEXT,
        `VERSION`       INT,
        `VERSIONUUID`   CHAR ( 50 )
);
CREATE TABLE fhemb64filesave (
        `filename`      TEXT,
        `content`       BLOB
);
CREATE INDEX config_idx ON fhemconfig (
        `versionuuid`,
        `version`
);

FLUSH PRIVILEGES;

Und ein googlen nach 'mysql blob size' sagt dann:

TINYBLOB   from 0 to 255 bytes
BLOB   from 0 to 65535 bytes
MEDIUMBLOB   from 0 to 16 777 215 bytes
LONGBLOB   from 0 to 4 294 967 295 bytes

Kann das sein, dass das meine Fehlerquelle ist??

[betateilchen]

Sorry, ich habe aktuell aus familiären Gründen keine Zeit, mich intensiv mit FHEM zu beschäftigen.

Aber zwei Dinge fallen mir in Deinem letzten Beitrag sofort auf:

• Du verwendest die gleiche Datenbank (fhem) für DbLog UND für configDB - davon habe ich in der Vergangenheit regelmäßig abgeraten, weil das auch schonmal zu Problemen führte.
• configDB verwendet in der Tabelle 'fhemb64filesave' für das Feld 'content' standardmäßig den Datentyp MEDIUMBLOB und nicht BLOB

Code: [Auswählen]

# create TABLE fhemb64filesave if nonexistent
if($cfgDB_dbtype eq "MYSQL") {
$fhem_dbh->do("CREATE TABLE IF NOT EXISTS fhemb64filesave(filename TEXT, content MEDIUMBLOB)");

Offenbar wurden die Tabellen in Deiner Datenbank nicht von configDB selbst angelegt.

[persching]

Sorry, ich habe aktuell aus familiären Gründen keine Zeit, mich intensiv mit FHEM zu beschäftigen.

Aber zwei Dinge fallen mir in Deinem letzten Beitrag sofort auf:

• Du verwendest die gleiche Datenbank (fhem) für DbLog UND für configDB - davon habe ich in der Vergangenheit regelmäßig abgeraten, weil das auch schonmal zu Problemen führte.
• configDB verwendet in der Tabelle 'fhemb64filesave' für das Feld 'content' standardmäßig den Datentyp MEDIUMBLOB und nicht BLOB

Code: [Auswählen]

# create TABLE fhemb64filesave if nonexistent
if($cfgDB_dbtype eq "MYSQL") {
$fhem_dbh->do("CREATE TABLE IF NOT EXISTS fhemb64filesave(filename TEXT, content MEDIUMBLOB)");

Offenbar wurden die Tabellen in Deiner Datenbank nicht von configDB selbst angelegt.

Die Datenbank selbst wurde vom init-script bei der Erstellung des Docker-Containers angelegt. Und ich glaube, das muss auch erstmal so so sein, denn sonst läuft das ganze Docker-konstrukt nicht hoch.

Und ja, ich nutze configDB und LogDB in einer Datenbank. Ich hatte die letzten 3 Jahre damit keine Probleme... zumindest nicht bewusst. Aber da ich mich jetzt intensiv mit dem Thema Docker, fhem und Datenbank beschäftigt habe werde ich zeitnah nochmal den Versuch alles in die MariaDB umzuziehen starten.

Das Problem lag tatsächlich im Unterschied "BLOB" und "MEDIUMBLOB". Ich habe das Initscript geändert, alle Daten der Datenbank gelöscht und sie erneut gebildet. Danach habe ich einen SQL-Dump per Befehlszeile wieder eingespielt (was aufgrund der History mehrere Stunden gedauert hat) und nun funktioniert alles wieder wie gewollt.
Danke für die Unterstützung und für eure Geduld.

[Wernieman]

Mit anderen Worten war es kein Docker/FHEM Problem, sondern ein Datenbank-Anlegen-Problem .....

[betateilchen]

Mit anderen Worten war es kein Docker/FHEM Problem,

und vor allem kein configDB Problem 

[betateilchen]

Die Datenbank selbst wurde vom init-script bei der Erstellung des Docker-Containers angelegt. Und ich glaube, das muss auch erstmal so so sein, denn sonst läuft das ganze Docker-konstrukt nicht hoch.

Bitte verwechsle nicht "Anlegen der Datenbank" und "Anlegen von Tabellen in der Datenbank".

[persching]

So und weil ich jetzt gerade so schön im Flow war habe ich jetzt einen Umzug von mysql 5.7 zu mariadb:latest im Docker gemacht und dann auch gleich noch berücksichtigt, dass ich 2 Datenbanken erstelle... eine fhem die alle configs enthält und eine fhemlog mit current und history.

Mal schauen, ob das alles dann so funktioniert. Im Moment sieht es gut aus. Ich kann alles speichern, Docker neu starten und alles läuft prima.