[SOLVED] Datenbank Update (5.2.3) - Could not apply migration - 1118 Row size too large

Shopware 5 Administration
1

Hallo,

für folgendes Problem habe ich schon einige Nachforschungen angestellt und einiges ausprobiert, komme allerdings auf keinen grünen Zweig. Ähnliche Update-Probleme habe ich hier im Forum zwar schon gesehen, aber keines mit genau diesem Text (sofern ich es nicht übersehen habe). Daher eröffne ich einen eigenen Thread .

 

Folgendes: Beim Update per Backend-Updater auf Shopware Version 5.2.3 kam beim Punkt “Datenbank Migration”, “Datenbank Update durchführen” folgende Fehlermeldung:

 

—

Error

Received the following error message:

Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not countiing BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

Please try to fix this error and restart the update.

Response

{“valid”:false,“errorMsg”:"< siehe text oben>"}

—

 

Woran genau kann das liegen? Es wird keine spezielle Tabelle angegeben und alle Plugins sind bereits auf dem aktuellsten Stand. Das Prüfen der s_schema_version ergab auch keine Fehlermeldungen.

Weder das Frontend noch das Backend ist mehr erreichbar, wodurch auch kein Neustart des Updates möglich ist. Durch das Löschen des Ordners “update-assets” per FTP komme ich jetzt zwar wieder ins Backend rein, aber es werden stets Fehlermeldungen bezüglich der Datenbank angezeigt. Die Shopware Version an sich scheint zwar jetzt die Neueste zu sein, allerdings sind die Daten nun entweder fehlerhaft oder nicht (korrekt) migriert.

 

Somit bleibt mir aktuell nur eine Backup-Rückspielung. Aber wenn ich nicht weiß, wodurch das Problem verursacht wird, kann ich das Update nicht durchlaufen lassen. Hat hierzu jemand eine Idee?

2

Unterstützt deine Datenbank ggf. keine Varchar(500) Spalten?
Das könntest du einmal testen, indem du den Typ eines Feldes in der s_article_attributes manuell umstellst. Die Migration 708 findest du hier: shopware/708-attribute-administration.php at 5.2 · shopware/shopware · GitHub

Eines der Querries verursacht wohl den Fehler.

1 „Gefällt mir“
3

@Moritz Naczenski schrieb:

Unterstützt deine Datenbank ggf. keine Varchar(500) Spalten?
Das könntest du einmal testen, indem du den Typ eines Feldes in der s_article_attributes manuell umstellst. Die Migration 708 findest du hier: https://github.com/shopware/shopware/blob/5.2/_sql/migrations/708-attribute-administration.php

Eines der Querries verursacht wohl den Fehler.

 

Wie es aussieht, scheint genau das das Problem zu sein. VARCHAR(500) lässt sich nicht manuell einstellen und es kommt dabei stets auch die gleiche Meldung „1118 Row size too large. The maximum row size for the used table type, not countiing BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs“.

Ich habe nun ein Ticket an den Hoster der Datenbank gesandt und werde sehen, was sich machen lässt. Ich hoffe, dass das auch das einzige Problem bei dem Update auf Version 5.2.3 bleibt…

Vielen Dank für den Tipp und sehr rasche Antwort!

4

Hi,

passen die Systemvoraussetzungen? Also hat die Datenbank/MySQL die passende Version? Ggf. hängt es da schon einfach…

Sebastian

5

Hallo,

die Fehlermeldung des MySQL5 Daemon (v5.6.31) ist soweit korrekt, da derzeit pro Tabelle des Typs InnoDB eine maximale “row size” von 65535 möglich ist.

Wir haben uns die aktuelle Tabelle “s_articles_attributes” zusammen mit dem Kunden angesehen.

In diesem Fall wurden zuvor einige Spalten in der Speicherbreite erweitert, sodass bereits das erste ALTER TABLE Statement des Upgrade SQL fehlschlägt.

Hier das Layout der aktuellen Tabelle:

CREATE TABLE `s_articles_attributes` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `articleID` int(11) unsigned DEFAULT NULL,
  `articledetailsID` int(11) unsigned DEFAULT NULL,
  `attr1` varchar(255) COLLATE utf8_unicode_ci DEFAULT '0',
  `attr2` varchar(255) COLLATE utf8_unicode_ci DEFAULT '0',
  `attr3` varchar(255) COLLATE utf8_unicode_ci DEFAULT '0',
  `attr4` varchar(8000) COLLATE utf8_unicode_ci DEFAULT NULL,
  `attr5` varchar(8000) COLLATE utf8_unicode_ci DEFAULT NULL,
  `attr6` varchar(1100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `attr7` varchar(1100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `attr8` varchar(1500) COLLATE utf8_unicode_ci DEFAULT NULL,
...

 

Entsprechend muss zunächst geprüft werden, ob die jeweilige Speicherbreite auf VARCHAR(500) verkürzt werden kann, ohne einen Datenverlust zu erleiden.

Das angestrebte Layout der Tabelle (VARCHAR(500)) bleibt auf jeden Fall im Rahmen der maximalen “row size” und ist damit fehlerfrei anwendbar und nicht ursächlich.

1 „Gefällt mir“
6

@Profihost schrieb:

Hallo,

die Fehlermeldung des MySQL5 Daemon (v5.6.31) ist soweit korrekt, da derzeit pro Tabelle des Typs InnoDB eine maximale „row size“ von 65535 möglich ist.

Wir haben uns die aktuelle Tabelle „s_articles_attributes“ zusammen mit dem Kunden angesehen.

In diesem Fall wurden zuvor einige Spalten in der Speicherbreite erweitert, sodass bereits das erste ALTER TABLE Statement des Upgrade SQL fehlschlägt.

Hier das Layout der aktuellen Tabelle:

CREATE TABLE s_articles_attributes (
id int(11) NOT NULL AUTO_INCREMENT,
articleID int(11) unsigned DEFAULT NULL,
articledetailsID int(11) unsigned DEFAULT NULL,
attr1 varchar(255) COLLATE utf8_unicode_ci DEFAULT ‚0‘,
attr2 varchar(255) COLLATE utf8_unicode_ci DEFAULT ‚0‘,
attr3 varchar(255) COLLATE utf8_unicode_ci DEFAULT ‚0‘,
attr4 varchar(8000) COLLATE utf8_unicode_ci DEFAULT NULL,
attr5 varchar(8000) COLLATE utf8_unicode_ci DEFAULT NULL,
attr6 varchar(1100) COLLATE utf8_unicode_ci DEFAULT NULL,
attr7 varchar(1100) COLLATE utf8_unicode_ci DEFAULT NULL,
attr8 varchar(1500) COLLATE utf8_unicode_ci DEFAULT NULL,
…

 

Entsprechend muss zunächst geprüft werden, ob die jeweilige Speicherbreite auf VARCHAR(500) verkürzt werden kann, ohne einen Datenverlust zu erleiden.

Das angestrebte Layout der Tabelle (VARCHAR(500)) bleibt auf jeden Fall im Rahmen der maximalen „row size“ und ist damit fehlerfrei anwendbar und nicht ursächlich.

Vielen Dank für die Unterstützung!

Bezüglich der Kürzung der Felder gibt’s so zwar noch einiges zu tun, aber nun weiß ich auf jeden Fall was los ist und komme vorwärts. Ich habe den Post als Antwort des Threads markiert.