# Mysqldump einspielen

**URL:** <https://forum.shopware.com/t/mysqldump-einspielen/61016>\
**Category:** Installation / Einstieg\
**Created:** [12. August 2019 um 12:10 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016 "2019-08-12T12:10:49Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![pino](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/pino/32/14373_2.png) [@pino](https://forum.shopware.com/u/pino)\
**Post date:** [13. Dezember 2021 um 12:33 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/62 "2021-12-13T12:33:53Z")

</div>

bist du sicher, dass das backup verändert wurde?  
`COLLATE utf8mb4_unicode_ci GENERATED ALWAYS AS`  
wird zu  
`GENERATED ALWAYS AS`

---

<div class="post-metadata">

**Author:** ![NextMike](https://avatars.discourse-cdn.com/v4/letter/n/838e76/32.png) [@NextMike](https://forum.shopware.com/u/NextMike)\
**Post date:** [13. Dezember 2021 um 12:52 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/63 "2021-12-13T12:52:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Plotec](https://avatars.discourse-cdn.com/v4/letter/p/c4cdca/32.png) [@Plotec](https://forum.shopware.com/u/Plotec)\
**Post date:** [14. Dezember 2021 um 08:14 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/64 "2021-12-14T08:14:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [2. Februar 2022 um 10:36 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/65 "2022-02-02T10:36:27Z")

</div>

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.

```auto
  `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. 🤔

---

<div class="post-metadata">

**Author:** ![Max\_Shop](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Max\_Shop](https://forum.shopware.com/u/Max_Shop)\
**Post date:** [2. Februar 2022 um 11:21 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/66 "2022-02-02T11:21:44Z")

</div>

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 …

---

<div class="post-metadata">

**Author:** ![R4M](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/r4m/32/9983_2.png) [@R4M](https://forum.shopware.com/u/R4M)\
**Post date:** [2. Februar 2022 um 12:05 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/67 "2022-02-02T12:05:26Z")

</div>

Anmerkung:

Gerade bei SW6 habe ich mir angewöhnt, ein Dump nur über die Console zu machen.

```auto
mysqldump --hex-blob -u root --password=12345 meine_datenbank > meine_datenbank.sql

```

Und auch über die Console wieder einzuspielen. Passt Perfekt 🙂

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [2. Februar 2022 um 13:08 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/68 "2022-02-02T13:08:53Z")

</div>

@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…

---

<div class="post-metadata">

**Author:** ![Max\_Shop](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Max\_Shop](https://forum.shopware.com/u/Max_Shop)\
**Post date:** [2. Februar 2022 um 13:12 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/69 "2022-02-02T13:12:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Plotec](https://avatars.discourse-cdn.com/v4/letter/p/c4cdca/32.png) [@Plotec](https://forum.shopware.com/u/Plotec)\
**Post date:** [3. Februar 2022 um 07:13 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/70 "2022-02-03T07:13:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Max\_Shop](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Max\_Shop](https://forum.shopware.com/u/Max_Shop)\
**Post date:** [3. Februar 2022 um 11:16 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/71 "2022-02-03T11:16:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [3. Februar 2022 um 16:00 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/72 "2022-02-03T16:00:00Z")

</div>

Ich denke das sollte an der Version von mysqldump liegen.  
Hab mal bei drei Providern nachgesehen.

```auto
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. 😉

---

<div class="post-metadata">

**Author:** ![wrongspot](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/wrongspot/32/8901_2.png) [@wrongspot](https://forum.shopware.com/u/wrongspot)\
**Post date:** [3. Februar 2022 um 20:52 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/73 "2022-02-03T20:52:07Z")

</div>

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](https://docs.shopware.com/de/shopware-6-de/erste-schritte/systemvoraussetzungen)

---

<div class="post-metadata">

**Author:** ![shopwarer1638](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@shopwarer1638](https://forum.shopware.com/u/shopwarer1638)\
**Post date:** [23. Juni 2022 um 17:51 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/74 "2022-06-23T17:51:42Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![Deitron2](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@Deitron2](https://forum.shopware.com/u/Deitron2)\
**Post date:** [27. Juli 2022 um 13:58 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/75 "2022-07-27T13:58:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![btxtiger](https://avatars.discourse-cdn.com/v4/letter/b/ecae2f/32.png) [@btxtiger](https://forum.shopware.com/u/btxtiger)\
**Post date:** [25. Dezember 2022 um 00:43 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/76 "2022-12-25T00:43:23Z")

</div>

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:

```auto
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.:

```sql
# 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:

```sql
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;
```

---

<div class="post-metadata">

**Author:** ![GerdW](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@GerdW](https://forum.shopware.com/u/GerdW)\
**Post date:** [11. Januar 2023 um 08:34 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/77 "2023-01-11T08:34:32Z")

</div>

Entschuldigung, aber das kann doch keine Lösung sein, die erzeugten Skripte zu manipulieren um eine 1:1 Kopie einer Datenbank zu erhalten! 🙄

---

<div class="post-metadata">

**Author:** ![btxtiger](https://avatars.discourse-cdn.com/v4/letter/b/ecae2f/32.png) [@btxtiger](https://forum.shopware.com/u/btxtiger)\
**Post date:** [1. Februar 2023 um 17:01 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/78 "2023-02-01T17:01:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![fischernico1](https://avatars.discourse-cdn.com/v4/letter/f/b19c9b/32.png) [@fischernico1](https://forum.shopware.com/u/fischernico1)\
**Post date:** [17. Februar 2023 um 18:36 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/79 "2023-02-17T18:36:22Z")

</div>

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`

---

<div class="post-metadata">

**Author:** ![bettenundwohnen](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@bettenundwohnen](https://forum.shopware.com/u/bettenundwohnen)\
**Post date:** [18. März 2023 um 14:32 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/80 "2023-03-18T14:32:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![T.Meyer](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/t.meyer/32/21334_2.png) [@T.Meyer](https://forum.shopware.com/u/T.Meyer)\
**Post date:** [5. Mai 2023 um 09:09 UTC](https://forum.shopware.com/t/mysqldump-einspielen/61016/81 "2023-05-05T09:09:05Z")

</div>

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

> **[GitHub - Smile-SA/gdpr-dump: Utility that creates anonymized database dumps...](https://github.com/Smile-SA/gdpr-dump)**
>
> Utility that creates anonymized database dumps (MySQL only). Provides default config templates for Magento, Drupal and OroCommerce. - GitHub - Smile-SA/gdpr-dump: Utility that creates anonymized da...

Der Dump kann dann ohne Probleme in Mysql eingespielt werden

[Vorherige Seite](https://forum.shopware.com/t/mysqldump-einspielen/61016.md?page=3)
