configDB - Fehlermeldung nach August-Update

[SusisStrolch]

Habe nach längerer Zeit mal wieder einen Update durchgeführt (22.08.22).
Daran anschließend lies sich fhem nicht mehr starten.
Fehlerursache lt. log:

Code Auswählen Erweitern

root@fhem:/opt/fhem# /usr/bin/perl fhem.pl configDB
2022.08.22 14:32:05 1: PERL WARNING: DBD::mysql::db do failed: Unknown column 'versiontag' in 'field list' at configDB.pm line 370.
2022.08.22 14:32:05 1: PERL WARNING: DBD::mysql::db do failed: Table storage engine 'InnoDB' does not support the create option 'TRANSACTIONAL=1' at configDB.pm line 371.
DBD::mysql::db do failed: Table storage engine 'InnoDB' does not support the create option 'TRANSACTIONAL=1' at configDB.pm line 371.
2022.08.22 14:32:05 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem_configDB;host=192.168.254.20;port=3307 at configDB.pm line 371.


Einziger Workaround der mir auf die Schnelle einfiel war ein Roll-Back des configDB.pm Modules.
Wie migriere ich nun die configDB am geschicktesten, ohne meine Settings zu verlieren?

Edit: sehe gerade, das ich wohl nicht der Einzige bin...
https://forum.fhem.de/index.php/topic,128952.msg1233085.html#msg1233085

[betateilchen]

2022.08.22 14:32:05 1: PERL WARNING: DBD::mysql::db do failed: Unknown column 'versiontag' in 'field list' at configDB.pm line 370.
2022.08.22 14:32:05 1: PERL WARNING: DBD::mysql::db do failed: Table storage engine 'InnoDB' does not support the create option 'TRANSACTIONAL=1' at configDB.pm line 371.

Das sind zwei Probleme.

Die erste Warnung bezüglich der nicht vorhandenen Spalte "versiontag" wird in configDB.pm erkannt, diese Meldung im Log kann ignoriert werden.
Die zweite Warnung resultiert daraus, dass eben genau die Spalte versiontag fehlt, es zu einer Fehlermeldung kam und dann versucht wird, die Spalte anzulegen. Warum das wiederum zu einem Abbruch führt, kann ich im Moment noch nicht nachvollziehen. Das scheint auch kein generelles Problem zu sein, denn das wurde seinerzeit ausgiebig getestet und ist auch bisher nur zweimal aufgetreten. Wenn ich mal mehr Zeit habe, werde ich mich damit beschäftigen, ob man da noch irgendwas verbessern kann.

Einziger Workaround der mir auf die Schnelle einfiel war ein Roll-Back des configDB.pm Modules.
Wie migriere ich nun die configDB am geschicktesten, ohne meine Settings zu verlieren?

Manuell auf der mysql Konsole:

Code Auswählen Erweitern

ALTER TABLE fhemversions ADD VERSIONTAG char(50)

[betateilchen]

Das scheint ein datenbankspezifisches Problem zu sein

https://dba.stackexchange.com/questions/213411/how-to-remove-options-from-mariadb-tables

Muss mal schauen, wie ich das im Code unterbringe.

[CoolTux]

Ich hatte ja das selbe mit PostgreSQL. Hatte ich ja geschrieben.

[SusisStrolch]

Das scheint ein datenbankspezifisches Problem zu sein

https://dba.stackexchange.com/questions/213411/how-to-remove-options-from-mariadb-tables

Ja, da bin ich gestern auch schon drüber gestolpert.
Die Variante

Code Auswählen Erweitern


ALTER TABLE fhemversions transactional=default, row_format=default, engine=InnoDB;
ALTER TABLE fhemversions ADD COLUMN VERSIONTAG char(50);

hat das Problem gefixt.

Die Table war schon etwas älter - noch mit der 5er MariaDB erstellt.

Edit:
Vielen Dank nochmals fürs Suchen!