Received the following error message:
An exception occurred while executing 'ALTER TABLE product ADD category_ids json NULL AFTER category_tree': SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚stickerworld_sw6.pp.category_tree‘ in ‚CHECK‘
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„An exception occurred while executing 'ALTER TABLE product ADD category_ids json NULL AFTER category_tree':\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚stickerworld_sw6.pp.category_tree‘ in ‚CHECK‘“}
also laut der Firma SundS ITS welche für uns den IT Bereich übernimmt ist die Datenbank wohl gecrashed… wir spielen jetzt eine Backup vom vortag auf und dann mal schauen
Ich musste die Dateien wiederherstellen und zöger jetzt noch ob das SQL Backup auch muss. Soweit ich es einschätzen kann läuft das jetzt erstmal wieder normal. Ist Maria DB Version 10.5.10-MariaDB-1:10.5.10.
Weiß jmd ob das SQL Update im Shopware Update Prozess als EINE Transaktion ausgeführt wird? Also gibts einen kompletten RollBack wenn das Update scheitert? Ansonsten komme ich ja nicht drum rum.
ich bin immer wieder erstaunt, wieviele Shopbetreiber „einfach mal so“ Updates/Upgrades ohne ein vernünftiges Dev/Test/Prod Konzept einspielen und sich dann wundern. Sind das alles Hobby-Shops ?
Jedem Shop-Betreiber ist angeraten, die Dev/Test/Prod Prinzipien zu befolgen, für Server-Sicherheit zu sorgen, uvm. - ansonsten geht das irgendwann echt in die Hose (Stichwort DSGVO und mögliche einhergehende Strafen) …
Und Applikations-Sicherheit ist kein Thema Eures Hosters.
Wir haben das gleiche Problem. Hat jemand eine Lösung gefunden? Eine Datenbank crasht ja nicht einfach so, da würfelt keiner beim Update. Bei uns betrifft es einen relativ frisch installierten noch nicht aktiven Shop beim Upgrade von 6.4.0.0 auf 6.4.1.1.
Und @scoopex was soll denn das Gepöbel? Das ist erstens überhaupt nicht zielführend und zweitens hat niemand hier gesagt, dass es im Produktivshop passiert ist. Mal davon abgesehen sollte man davon ausgehen können, dass Updates im Stable-Channel einem nicht den kompletten Shop zerschießen.
Wir haben auch große Probleme mit dem Update von 6.3.5.3 auf 6.4.1.1!
Der erste Shop lief durch. Bei zweiten und dritten Shop stieg das Upgrade-Script (ausgeführt über Admin-Dashboard) bei der Migration der DB mittendrin aus.
Ich habe den Umsteieg vorher jeweils mehrfach über eine Staging-Umgebung getestet. Da lief es nach anfänglichen Schwierigkeiten dann durch (musste bestimmte Plugins entfernen).
Fehler bei Shop #2 war dieser hier:
rror
Received the following error message:
An exception occurred while executing 'ALTER TABLE `product` DROP FOREIGN KEY `fk.product.cms_page_id`': SQLSTATE[42S22]: Column not found: 1054 Unknown column '`www5`.`product.parent`.`category_tree`' in 'CHECK'
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"An exception occurred while executing 'ALTER TABLE `product` DROP FOREIGN KEY `fk.product.cms_page_id`':\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column '`www5`.`product.parent`.`category_tree`' in 'CHECK'"}
Nachdem dann alle Daten wieder zurückgespielt wurden, habe ich es wieder über die Staging versucht und dort lief alles. Dann erneuter Versuch auf dem Live-System und diesmal lief die Migration der DB glatt durch!
Ich habe leider überhaupt keine Erklärung für diesen Fall. Aber, mit Shop #3 exakt das selbe. Nun spiele ich die Backups wieder zurück und versuche es erneut.
Backups der Datenbank und Dateien sind also noch wichtiger denn je.
Das ist ja echt seltsam. Habt ihr nur die Dateien oder auch die Datenbank wiederhergestellt? Theoretisch sollte die Migration ja in einer Transaktion laufen und keine Änderungen durchgeführt haben, aber bei uns ist es auch nach dem Wiederherstellen der Dateien erneut gekracht.
Wiederherstellung der DB und des htdocs-Verzeichnis. Das Upgrade hängt sich mittendrin auf, die Dateien wurden schon aktualisiert und die DB ist inkonsistent, da mittendrin abgebrochen.
Echt nicht zu empfehlen, derzeit das Upgrade auf 6.4 durchzuführen.
Das ist auch seltsam. Das .parent sieht mir zuviel aus. Im ursprünglichen Statement ALTER TABLE product ADD category_ids json NULL AFTER category_tree steht ja auch überhaupt nichts von parent.
Je nachdem wie Du die DB wiederhergestellt hast bleiben unter Umständen Tabellen „erhalten“, die durch die Migration auf 6.4 angelegt werden. Die Migration bricht dann aber ab, wenn diese Tabelle schon in der DB steht. Daher musste ich hier manuell eine Tabellen entfernen.
Nachdem uns heute der dritte Shop beim Upgrade auf 6.4.1.1 gecrashed ist, habe ich alle Dateien aus dem htdocs-Verzeichnis zurückgespielt und danach den Dump der DB eingespielt. Upgrade erneut laufen gelassen und siehe da: lief ohne Probleme durch, Shop ist nun auf 6.4.1.1
Ich vermute sehr stark, dass es an Inkonsistenzen innerhalb der DB liegt und durch das Einspielen eines „frischen Dumps“ dann alles bei der Migration der DB funktioniert.
P.S. Ich habe diesen Thread etwas gehighjacked, mein Upgrade war von 6.3.5.3 auf 6.4.1.1. Allerdings mit einer identischen Fehlermeldung wie @artistofmedia im ersten Beitrag gepostet hat. Auch ich hatte jedes mal ein ‚CHECK‘-Problem
Das ist ja wirklich kurios. Wir werden das dann auch mal mit einem Dump testen. Seltsamerweise ist ja unser System fast frisch installiert, die Datenbank hatte also noch nicht viele Gelegenheiten, kaputt zu gehen.
das war ein super Tipp!
Ich hatte ein ähnliches Problem beim Update auf 6.4.2.1
Da lief auch ein „alter table“ fehl. Da wir letzte Woche erst von SW 5.4 auf 6.4 umgestiegen sind und das Migration-Plugin verwendeten, vermute ich, dass beim Migration-Vorgang etwas in der DB kaputt gegangen ist.
Danke An eurer Migration sollte es aber nicht gelegen haben, die dürfte eigentlich nur Daten kopieren und nichts am Schema verändern. Bei uns ist es ja auch mit einem ganz frisch installierten Shopware 6 ohne Datenmigration aufgetreten.
Man ist das ein Bockmist. Das gleiche Spiel beim Update auf 6.4.2.1 mit einer anderen Spalte:
Error
Received the following error message:
An exception occurred while executing ' ALTER TABLE payment_method_translation ADD COLUMN distinguishable_name VARCHAR(255) NULL AFTER name ': SQLSTATE[42S22]: Column not found: 1054 Unknown column 'shopware_xxx.payment_method.translation.custom_fields' in 'CHECK'
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"An exception occurred while executing '\n ALTER TABLE payment_method_translation\n ADD COLUMN distinguishable_name VARCHAR(255) NULL AFTER name\n ':\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column 'shopware_xxx.payment_method.translation.custom_fields' in 'CHECK'"}
Was soll denn der Mist mit dem ADD COLUMN [...] AFTER überhaupt? Wäre super, wenn die referenzierten Spalten dann wenigstens existieren würden.
An eurer Migration sollte es aber nicht gelegen haben, die dürfte eigentlich nur Daten kopieren und nichts am Schema verändern. Bei uns ist es ja auch mit einem ganz frisch installierten Shopware 6 ohne Datenmigration aufgetreten.