DB-Schemaupgrade bei Upgrade von 2.13.1 auf 2.14.2 schlägt fehl

Welche Distribution genau setzen Sie denn ein? MySQL 5.5 ist schon extrem alt.

Eventuell kann die MySQL-Einstellung innodb_large_prefix helfen.

Zitat von dkrause

Es ist (leider) noch ein altes Debian 8.

Debian 8 LTS ist seit zwei Jahren "end-of-life" (30.06.2020).
Unser Fehler bestand darin, dass wir für die 2.14-Version keine entsprechende Paketabhängigkeit eingerichtet haben, damit kein (versehentliches) Upgrade möglich ist.

Zitat

Die MySQL-Option war/ist schon aktiv. leider legt das Update neue Tabellen mit der Kollation utf8mb4 an. Meiner Meinung nach wäre nur ein reines utf8 notwendig.

Nein, es gibt Unicode-Zeichenklassen die MySQL eben nur in utf8mb4 korrekt speichern kann (z.B. Emoticons, die auch in vielen IDN-Domainnamen erlaubt sind).

Zitat

utf8mb4 sprengt das Limit. Das hätte in den Release Note kommuniziert werden müssen. Erst ab MariaDB 10.2.2 dürften die Voraussetzungen für ein problemloses Update erfüllt sein.

Wir haben mit v2.14.3 nun die Optionen "charset" und "collation" für die Konfigurationsanweisung db_options eingeführt. Damit kann (falls zwingend erforderlich) von utf8mb4 auf utf8 umgeschaltet werden. Allerdings wird eine solche LiveConfig-Datenbank nicht mit komplexen UTF8-Zeichen umgehen können (man muss dann später die Datenbank manuell auf utf8mb4 konvertieren).

Die wirklich einfachste Lösung wäre, den Server zu aktualisieren (siehe Anleitung). Der Debian 9 LTS-Support läuft diese Woche auch aus, d.h. zum Ende diesen Jahres wird LiveConfig auch das nicht mehr unterstützen.

Hallo!

Ich habe hier das gleiche Problem mit CentOS 7 und MySQL 5.6.51 - innodb_large_prefix sind aktiv, als SQL Mode ist noch "NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES" hinterlegt.

Ich hänge nicht an der MySQL Anbindung von LiveConfig - gibt es ansonsten ein mini Howto (wie https://www.liveconfig.com/de/kb/sqlite-mysql/) um von MySQL wieder zu SQLITE zu gehen? Auch mit der aktuell "fehlerhaften" Datenbank?

Vielen Dank!

Der einfachste Weg wäre tatsächlich, mit der 2.14.3 und db_options = "charset=utf8,collation=utf8_unicode_ci" die Datenbank eben mit "nur" utf8 zu verwenden. Wenn später irgendwann mal auf MySQL >= 5.7 oder MariaDB >= 10.1 aktualisiert wird, lassen sich die Tabelleneinstellungen relativ einfach ändern (ALTER TABLE tablename CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;)

Eine Migration von MySQL auf SQLite haben wir bislang noch nicht geplant.

Da aber scheinbar noch viele "Antik-Systeme" im Einsatz sind prüfen wir heute, ob LC die Version der Backend-Datenbank erkennen kann und dann selbständig auf utf8 schaltet.

Hallo,

okay, alles klar - habe auf MySQL 5.7 umgestellt.

VG

Oh, danke für den Hinweis. Wird gleich korrigiert.

Wir arbeiten aber bereits an einer komfortableren Lösung. Wenn LiveConfig erkennt, dass das Backend "zu alt" ist, soll es selbständig (ohne Anpassung in der liveconfig.conf) auf utf8 wechseln.

Viele Grüße

-Klaus Keppler

Ab v2.14.3 (Preview, gestern aktualisiert) prüft LiveConfig ob die MySQL-Datenbank utf8mb4 mit "langen" Indizes unterstützt. Wenn das nicht der Fall ist, erfolgt die Migration und der Zugriff mit utf8.
Wir haben das erfolgreich mit MySQL 5.5 durchgespielt.

Man bekommt alte MySQL/MariaDB-Installationen übrigens durchaus dazu, auch lange Indizes zu unterstützen. Der "Trick" besteht darin, dass manche Einstellungen in der MySQL-Konfiguration auf "1" statt auf "ON" gesetzt werden müssen (ist ein Bug in älteren MySQL-Versionen).
In der Regel genügt es, eine Datei z.B. in /etc/mysql/conf.d/99-innodb.conf anzulegen und anschließend MySQL neu zu starten:

[mysqld]
innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_file_per_table = 1

MySQL <5.6 und MariaDB <10.2 brauchen die Option "innodb_file_per_table" (bei neueren Versionen klappt das auch ohne diese Einstellung, die dann aber auch eh standardmäßig aktiv ist).
Manchmal liest man auch was von der Einstellung "innodb_default_row_format". LiveConfig braucht diese nicht, neuere MySQL-Versionen unterstützen diese auch nicht mehr.