Ein großer Import über eine Weboberfläche scheitert fast immer: das Upload-Limit, die Ausführungszeit oder die Anfrage-Zeitgrenze bricht ihn mittendrin ab. Importieren Sie von der Kommandozeile, dann gilt nichts davon.

mysql -u user -p dbname < dump.sql
# or, compressed
zcat dump.sql.gz | mysql -u user -p dbname

Machen Sie ihn schnell

# at the top of the session
SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
-- import --
SET foreign_key_checks=1;
SET unique_checks=1;
COMMIT;

Die meiste Zeit eines großen Imports geht für das Prüfen von Constraints und das Schreiben nach jeder Zeile drauf. Das für einen vertrauenswürdigen Dump abzuschalten und danach wieder einzuschalten macht regelmäßig aus Stunden Minuten.

Nur bei einem Dump, dem Sie trauen, und auf einer Datenbank, in die sonst nichts schreibt. Mit abgeschalteter Fremdschlüsselprüfung spielt ein kaputter Dump stillschweigend kaputte Daten ein.

Sehen Sie ihm zu

pv dump.sql | mysql -u user -p dbname

pv zeigt einen Fortschrittsbalken und eine Restzeit an. Ohne das ist ein langer Import nicht von einem hängenden zu unterscheiden, und man bricht ihn auf halber Strecke ab — was schlimmer ist als zu warten.

Wenn er mittendrin scheitert

  • Platte voll — die Datenbank braucht Platz für die Daten UND für die temporären Dateien. Prüfen Sie df -h, bevor Sie anfangen.
  • MySQL server has gone away — eine einzelne Zeile ist größer als max_allowed_packet. Erhöhen Sie ihn: max_allowed_packet = 256M.
  • Unknown collation — der Dump stammt aus einem neueren MySQL. Entweder aktualisieren oder die Sortierung in der Datei umschreiben.
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' dump.sql
Importieren Sie in eine leere Datenbank, nicht über eine laufende. Scheitert es auf halber Strecke, haben Sie eine halb eingespielte Kopie zum Wegwerfen statt einer halb zerstörten Website.