Probleme beim Update auf Liveconfig 2.16.0 wenn Liveconfig mit MySQL läuft

1. offizieller Beitrag

    Es gibt ein Problem das auftreten kann wenn man Liveconfig auf Version 2.16.0 aktualisiert auf Servern mit Liveconfig in einer MySQL Datenbank und die von Debian 8 an per Dist-Upgrade aktualisiert wurden.


    Hier in diesem Beispiel ist aktuell Debian 10 installiert.


    Wenn Liveconfig startet will es die Datenbankstruktur aktualisieren und bringt dann folgende Meldung:


    [2023/05/30 17:55:55.177138] [11214|11214] Upgrading database schema (r216001 -> 2.16.0-2)
    [2023/05/30 17:55:55.187047] [11214|11214] Upgrading database schema (r216002 -> 2.16.0-3)
    [2023/05/30 17:55:55.199261] [11214|11214] Upgrading database schema (r216003 -> 2.16.0-4)
    [2023/05/30 17:55:55.219040] [11214|11214] Database connection failed: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs


    Wenn man die Datenbank aus einem Backup einspielt kann das Upgrade erfolgreich durchgeführt werden da die InnoDB Struktur der von MariaDB 10.3 entspricht. Leider hilft es nichts die halb aktualisierte Datenbank zu sichern und neu einzuspielen da dann folgender Fehler kommt wenn man Liveconfig starten möchte:


    [2023/05/30 18:00:11.440416] [12549|12549] Database connection failed: Duplicate column name 'HP_MAILLIMIT_HOUR'


    Anscheinend wird das Upgrad auf die Struktur r216004 nur halb durchgeführt aber die entsprechenden Spalten sind schon vorhanden und leider habe ich keine Möglichkeit zu sehen welche Abfragen beim Upgrade von r216003 auf r216004 durchgeführt wurden so das ich die entsprechenden Spalten wieder entfernen kann oder aber den Rest von dem Upgrade auf r216004 manuell durchführen kann.

    Das Problem hatte ein anderer Anwender auch schon, wir arbeiten bereits an einer Lösung.


    Um das aufzuklären: die Tabellen alter Datenbanken haben ein Zeilenformat (row format), welches hier Probleme macht. Details und Lösungsmöglichkeiten finden sich hier: https://mariadb.com/kb/en/trou…to-the-dynamic-row-format


    Unser Ansatz ist, dass LiveConfig während des Upgrades prüft, ob noch Tabellen in einem anderen row format als "DYNAMIC" vorhanden sind, und deren Format dann on-the-fly anpasst.
    Ich gebe Bescheid, sobald das Update verfügbar ist.


    Viele Grüße


    -Klaus Keppler

    Zitat von RipClaw

    Anscheinend wird das Upgrad auf die Struktur r216004 nur halb durchgeführt aber die entsprechenden Spalten sind schon vorhanden und leider habe ich keine Möglichkeit zu sehen welche Abfragen beim Upgrade von r216003 auf r216004 durchgeführt wurden so das ich die entsprechenden Spalten wieder entfernen kann oder aber den Rest von dem Upgrade auf r216004 manuell durchführen kann.


    Folgende Schemaänderungen werden von 2.16.0-3 auf 2.16.0-4 ausgeführt:

    Code
    ALTER TABLE HOSTINGPLANS ADD HP_MAILLIMIT_HOUR INTEGER DEFAULT -1 NOT NULL;
ALTER TABLE HOSTINGCONTRACTS ADD HC_MAILLIMIT_HOUR INTEGER;
ALTER TABLE MAILBOXES ADD MB_LIMIT_HOUR INTEGER;
ALTER TABLE MAILBOXES ADD MB_LIMIT_STATUS TINYINT UNSIGNED DEFAULT 0 NOT NULL;
ALTER TABLE MAILBOXES ADD MB_LIMIT_LASTBLOCKED DATETIME;
ALTER TABLE MAILBOXES ADD MB_LIMIT_BLOCKCOUNT INTEGER UNSIGNED DEFAULT 0 NOT NULL;
ALTER TABLE MAILSERVERS ADD MS_HIDE_SENDER_IP TINYINT UNSIGNED DEFAULT 0 NOT NULL;
    Zitat von kk

    Folgende Schemaänderungen werden von 2.16.0-3 auf 2.16.0-4 ausgeführt:

    Code
    ALTER TABLE HOSTINGPLANS ADD HP_MAILLIMIT_HOUR INTEGER DEFAULT -1 NOT NULL;
ALTER TABLE HOSTINGCONTRACTS ADD HC_MAILLIMIT_HOUR INTEGER;
ALTER TABLE MAILBOXES ADD MB_LIMIT_HOUR INTEGER;
ALTER TABLE MAILBOXES ADD MB_LIMIT_STATUS TINYINT UNSIGNED DEFAULT 0 NOT NULL;
ALTER TABLE MAILBOXES ADD MB_LIMIT_LASTBLOCKED DATETIME;
ALTER TABLE MAILBOXES ADD MB_LIMIT_BLOCKCOUNT INTEGER UNSIGNED DEFAULT 0 NOT NULL;
ALTER TABLE MAILSERVERS ADD MS_HIDE_SENDER_IP TINYINT UNSIGNED DEFAULT 0 NOT NULL;


    Danke für die schnelle Reaktion und die Informationen. Zum Glück wurde auf dem Server an diesem Tag nichts gemacht. Daher konnte ich mit dem Backup von der Nacht vorher das Problem beheben.

    Hallo,
    ich habe gestern Nacht einen Server von Debian 9 auf 10 (ich weiss..) aktualisiert. Im Zuge des Updates kam es zu den Fehlern
    - "Row size too large...."
    - Duplicate column name 'HP_MAILLIMIT_HOUR'
    - Duplicate column name 'HC_MAILLIMIT_HOUR'

    Ich habe in der DB, entsprechend dem Schemaänderungs-Code von kk, die Spalte HP_MAILLIMIT_HOUR in der Tabelle HOSTINGPLANS und HC_MAILLIMIT_HOUR in der Tabelle HOSTINGCRONTRACTS umbenannt (hinten was angehängt).
    Nach Neustart vom liveconfig mittels systemctl restart liveconfig.service kommt weiterhin eine Fehlermeldung:

    Code
    Okt 04 13:19:25 liveconfig[23176]:  - /usr/sbin/liveconfig: LiveConfig 2.16.0-release starting...
Okt 04 13:19:25 liveconfig[23176]:  - /usr/sbin/liveconfig: Database driver loaded: MySQL (3.3.4)
Okt 04 13:19:25 liveconfig[23176]:  - /usr/sbin/liveconfig: Upgrading database schema (r216003 -> 2.16.0-4)
Okt 04 13:19:25 liveconfig[23176]:  - /usr/sbin/liveconfig: Database connection failed: Duplicate column name 'HP_MAILLIMIT_HOUR'
Okt 04 13:19:25 liveconfig[23176]:  - /usr/sbin/liveconfig: Closing log file
Okt 04 13:19:25 systemd[1]: liveconfig.service: Control process exited, code=exited, status=1/FAILURE

    Wie gehe ich da jetzt am Besten vor?

    Vielen Dank für die Mühe,
    schönen Gruß,
    Udo Pütz (Admin)

    • Offizieller Beitrag

    Hallo,

    es handelt sich da um ein immerhin sehr seltenes Problem (nur bei Migrationen sehr "alter" MySQL-Datenbanken).

    Mit der kommenden Version (2.16.1) aktualisieren wir nun das Datenbankformat so, dass die Meldung "Row size too large" da nicht mehr auftreten sollte.


    Das Vorgehen wäre wie folgt:1.) folgenden SQL ausführen:

    SQL
    UPDATE LIVECONFIG SET LC_VALUE='0216004' WHERE LC_KEY='dbschema' AND LC_VALUE < '0216004'

    (ausschließlich in diesem speziellen Einzelfall, weil die o.g. Schemaänderungen ja offenbar bereits durchgeführt wurden)

    2.) aktuelle LiveConfig-Preview installieren:

    Code
    cd /tmp
wget https://repo.liveconfig.com/debian-test/pool/main/l/liveconfig/liveconfig_2.16.1-dev20230711.1_amd64.deb
dpkg -i liveconfig_2.16.1-dev20230711.1_amd64.deb


    Danach sollte LiveConfig die restlichen Schemaänderungen ausführen können und normal starten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden