bist du sicher, dass das backup verändert wurde?
COLLATE utf8mb4_unicode_ci GENERATED ALWAYS AS
wird zu
GENERATED ALWAYS AS
ja, das wird es. Ich sehe gerade, dass beim Import des editierten Dumps ein anderer Fehler auftaucht:
ERROR 1067 (42000) at line 583: Invalid default value for ‚cms_page_version_id‘
Evtl. weil ich ohne --hex-blob exportiert habe. Da kann ich mich leider nicht mehr erinnern. Ich teste beide „Tricks“ mal bei Gelegenheit. Ich kam ja weiter mit dem phpMyAdmin.
Ich habe jetzt die betreffenden Spalten im Insert gelöscht und jetzt gehts. Die Spalten werden beim Import neu erstellt und befüllt. Im betreffenden Shop sind nur eine handvoll Bestellungen drin, da geht das ja noch aber wenn man hunderte oder tausende Bestellungen hat bearbeitet man die Datei mal nicht ebenso.
Also bleibt immer noch die Frage: Mit welchen Parametern dumpen damit generierte Spalten nicht im Dump enthalten sind?
Edit
Ich habe jetzt mal verschiedene Dumps von der korrekt zurückgesicherten Datenbank gemacht. Weder mit mysqldump noch mit Adminer bekomme ich einen Dump ohne generierte Spalten in den Inserts hin. Nur phpmyadmin exportiert ohne generierte Spalten in den Inserts, im Quick Mode in der Standardeinstellung.
Ich sitze nun auch vor dem Problem, dass ich vor einem Update die Datenbank nicht kopieren kann.
Wie bereits genannt, hilft es nur weiter, im Dump die entsprechenden Spalten zu löschen.
Bei mir erzeugt leider auch der phpMyAdmin im Quick Mode die eigentlich zu generierenden Spalten.
`order_date` date GENERATED ALWAYS AS (cast(`order_date_time` as date)) STORED,
`amount_total` double GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.totalPrice'))) VIRTUAL,
`amount_net` double GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.netPrice'))) VIRTUAL,
`position_price` double GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.positionPrice'))) VIRTUAL,
`tax_status` varchar(255) GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.taxStatus'))) VIRTUAL,
`shipping_costs` json NOT NULL,
`shipping_total` double GENERATED ALWAYS AS (json_unquote(json_extract(`shipping_costs`,_utf8mb4'$.totalPrice'))) VIRTUAL,
Es kann doch nicht die Lösung sein, manuell alle GENERATED Felder zu löschen. 
Entweder eine aktuelle Version von mysqldump nutzen oder per phpmyadmin erstellen lassen. Dann gibt es das Problem nicht. Ansonsten, doch… die Zeilen auskommentieren. Per PHP Script oder …
Anmerkung:
Gerade bei SW6 habe ich mir angewöhnt, ein Dump nur über die Console zu machen.
mysqldump --hex-blob -u root --password=12345 meine_datenbank > meine_datenbank.sql
Und auch über die Console wieder einzuspielen. Passt Perfekt 
1 „Gefällt mir“
@Max_Shop phpMyAdmin und Adminer zeigen den identischen Fehler
@R4M Danke für den Hinweis. So funktioniert es. Finde es trotzdem traurig, dass phpMyAdmin und Adminer nicht genutzt werden können…
Ich habe in Stackoverflow gelesen, dass nur alte Versionen von mysqldump dieses Problem erzeugen, ebenso Adminer in der aktuellen Version.
Es geht nicht ums einspielen, sondern um die dump Erstellung.
Anscheinend habt ihr eine Lösung gefunden, ist ja top.
So unterschiedlich sind die Erfahrungen. Bei mir funktioniert nur die phpmyadmin Lösung. Denn phpmyadmin dumpt ohne die generierten Spalten. Somit funktioniert auch das wiederherstellen problemlos wenn vorher die Fremdschlüsselüberprüfung ausgeschaltet wird.
Im Dump von mysqldump bleiben die generierten Spalten erhalten und somit gibt’s dann Fehler beim wiederherstellen. Die Tabellen werden zwar angelegt aber die Daten fehlen dann. Da man sich bei einem Hoster die mysqldump Version nicht aussuchen kann ist das auch keine Lösung.
Mein Problem ist nun das ich per Cronjob jede Nacht ein Backup der Dateien und der Datenbank über mysqldump mache, diesen Dump aber nicht fehlerfrei wiederherstellen kann, da die generierten Spalten enthalten sind und diese mysqldump bzw. Mysql Version diesen Fehler eigentlich nicht haben sollte.
Im Moment mache ich alle paar Tage einen manuellen Dump mit phpmyadmin da das für mich die einzige funktionierende Lösung darstellt. Ich möchte mich aber darum gar nicht kümmern müssen und eine automatische Möglichkeit mit mysqldump nutzen.
Mit einem recht einfachen PHP-Script könntest du die Zeilen aus dem dump entfernen lassen. Ist umständlich, würde aber automatisiert erfolgen. Oder du versuchst den mysqldump von einem anderen Server, vielleicht funktioniert es ja dann.
Ich denke das sollte an der Version von mysqldump liegen.
Hab mal bei drei Providern nachgesehen.
Provider 1: (funktioniert bei mir)
mysqldump Ver 10.13 Distrib 5.7.18, for Linux (i686)
Provider 2:
mysqldump Ver 10.16 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64)
Provider 3:
mysqldump Ver 10.19 Distrib 10.6.5-MariaDB, for debian-linux-gnu (x86_64)
Die niedrigste Versionsnummer funktioniert bei mir.
Evtl. könnte es auch ein Unterschied zwischen MySQL und MariaDB sein. 
Es ist definitiv mysql vs. MariaDb. Beide Datenbanken implementieren virtuelle Spalten anders. Daher kann ein dump vom MySQL nicht ohne weiteres zu Maria dB importiert werden und umgekehrt. Außerdem ist deine mysql Version fehlerhaft, shopware setzt mindestens 5.7.21 voraus Shopware 6 - Erste Schritte - Systemvoraussetzungen
when we while duplicating the setup faced this problem with order tables, this helped us (MySQL 5.7):
- do SQL export via PHPMyAdmin
- do import via simple CLI mysql command:
mysql -h hostaddress -u dbu999 -p db9999 < db9999-1111.sql
All works then without workarounds,
hope this helps, have time to enjoy the nature!
1 „Gefällt mir“
MariaDB 10.3.34 nach MariaDB 10.3.22 hat einen Syntax Error bei der Zeile tax_status varchar(255) COLLATE utf8mb4_unicode_ci GENERATED ALWAYS AS (json_unquote(json_extract(price,'$.taxStatus'))) VIRTUAL, geworfen.
Nach einem Upgrade auf MariaDB 10.3.35 hat es funktioniert.
Ich hatte das gleiche problem mit MySQL 8.0.31 (NICHT mariadb!). Der via Adminer exportierte Dump ließ sich nachher nicht wieder importieren.
Die Ursache des Problems betrifft alle Spalten die in der Definition ... GENERATED ALWAYS AS ... beinhalten. Für diese Spalten existieren im dump INSERT values, welche aber nicht erlaubt sind. Daher habe ich zusätzliche temporäre ersatz Spalten hinzugefügt und die INSERT INTO ... statements verändert. Dies ist überschaubar viel Arbeit als alle Values anzupassen. Zum Ersetzen hat sich sublime bei 500MB Datenbank stabiler als vscode erwiesen. Zu diesem Zeitpunkt (Shopware 6.4.18.0) betrifft dies die folgenden Spalten:
orders
`tmp_fix_1` TEXT, # `order_date`
`tmp_fix_2` TEXT, # `amount_total`
`tmp_fix_3` TEXT, # `amount_net`
`tmp_fix_4` TEXT, # `position_price`
`tmp_fix_5` TEXT, # `tax_status`
`tmp_fix_6` TEXT, # `shipping_total`
order_delivery_position
`tmp_fix_1` TEXT, # `total_price`
`tmp_fix_2` TEXT, # `unit_price`
`tmp_fix_3` TEXT, # `quantity`
order_line_item
`tmp_fix_1` TEXT, # `unit_price`
`tmp_fix_2` TEXT, # `total_price`
product
`tmp_fix_1` TEXT, # `variant_listing_config`
product_keyword_dictionary
`tmp_fix_1` TEXT, # `reversed`
Anschließen werden die INSERT statements angepasst, z.B.:
# statt
INSERT INTO `product_keyword_dictionary` (`id`, `language_id`, `keyword`, `reversed`) VALUES
# ändern zu
INSERT INTO `product_keyword_dictionary` (`id`, `language_id`, `keyword`, `tmp_fix_1`) VALUES
Somit kann das SQL Script fehlerfrei durchlaufen. Anschließend werden alle temporären Spalten entfernt:
ALTER TABLE order
DROP COLUMN tmp_fix_1,
DROP COLUMN tmp_fix_2,
DROP COLUMN tmp_fix_3,
DROP COLUMN tmp_fix_4,
DROP COLUMN tmp_fix_5,
DROP COLUMN tmp_fix_6;
ALTER TABLE order_delivery_position
DROP COLUMN tmp_fix_1,
DROP COLUMN tmp_fix_2,
DROP COLUMN tmp_fix_3;
ALTER TABLE order_line_item
DROP COLUMN tmp_fix_1,
DROP COLUMN tmp_fix_2;
ALTER TABLE product
DROP COLUMN tmp_fix_1;
ALTER TABLE product_keyword_dictionary
DROP COLUMN tmp_fix_1;
1 „Gefällt mir“
Entschuldigung, aber das kann doch keine Lösung sein, die erzeugten Skripte zu manipulieren um eine 1:1 Kopie einer Datenbank zu erhalten! 
Natürlich nicht, ich wollte nur meinen Lösungsweg teilen, für den Fall dass jemand ebenfalls vor einer zerstörten Instanz steht und eine Sofortlösung braucht.
Unsere Backup Lösung sichert grundsätzlich das gesamte MySQL Verzeichnis, also inkl. jeglicher Server Konfiguration. Dies erlaubt uns einen drop-in rollback zu machen, ohne Datenbank erstellen…dump importieren… etc.
Nichts desto trotz ist es natürlich dämlich, dass ein Dump nicht einfach importiert werden kann. Wenn ich Zeit habe einen stressfreien Lösungsweg zu suchen, werde ich mich mal da dran setzen
1 „Gefällt mir“
Die Datenbank an der ich gerade dran war hatte um die 7gb.
Ich habe zuerst die Struktur im PHPMYADMIN exportiert und per CLI importiert.
Im PHPMYADMIN bei exportieren die struktur aller tabellen auswählen und daten abwählen.
Diese Datei musste ich editieren an der Stelle CREATE ALGORITHM und habe CURRENT_USER eingesetzt.
CREATE ALGORITHM=UNDEFINED DEFINER=CURRENT_USER
mysql -h hostaddress -u dbu999 -p db9999 < struktur.sql
Anschließend habe ich die bei Exportieren für alle Datenbanktabellen Struktur ausgeschaltet und nur Daten angeschaltet. Mit Ausnahme der größeren Tabellen wie z.B. cart.
Die größeren Tabellen habe ich extra exportiert.
Anschließend musste ich noch die CREATE ALGORITHMS entfernen aus den Daten Dateien, da diese doppelt waren.
sed -i '/CREATE ALGORITHM/d' data1.sql
sed -i '/CREATE ALGORITHM/d' cart.sql
Import ging dann nur mit FOREIGN KEY CHECKS 0
mysql -h hostaddress --init-command="SET SESSION FOREIGN_KEY_CHECKS=0;" -u dbu999 -p db9999 < data1.sql
mysql -h hostaddress --init-command="SET SESSION FOREIGN_KEY_CHECKS=0;" -u dbu999 -p db9999 < cart.sql
Vielen Vielen Dank! In solchen Momenten bin ich dann doch dankbar, dass es das Forum gibt auch wenn es ansonsten eher sperrlich hilft. Hier hat es den Tag geretett.
Falls einer dasselbe Problem hat und per Google hierher findet:
Bei einem Wechsel von Maria zu MYSQL kann es zu Problemen kommen, da Mysql die „GENERATED ALWAYS“ Spalten nicht korrekt importieren kann.
Beispiel Spalte:
order_date date GENERATED ALWAYS AS (cast(order_date_time as date)) STORED
Um dieses Problem zu umgehen, muss der Dump nicht mit mysqldump erstellt werden, sondern über
Der Dump kann dann ohne Probleme in Mysql eingespielt werden
2 „Gefällt mir“