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:
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
Zitat von: SusisStrolch am 09 September 2022, 09:28:06
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.
Zitat von: SusisStrolch am 09 September 2022, 09:28:06
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:
ALTER TABLE fhemversions ADD VERSIONTAG char(50)
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.
Ich hatte ja das selbe mit PostgreSQL. Hatte ich ja geschrieben.
Zitat von: betateilchen am 09 September 2022, 17:59:33
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
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!