Mysqldump einspielen

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. :thinking:

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 :slight_smile:

1 Like

@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. :thinking:
Evtl. könnte es auch ein Unterschied zwischen MySQL und MariaDB sein. :wink:

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):

  1. do SQL export via PHPMyAdmin
  2. 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!