Import einer sehr großen DB

**knows MySQLDumper** Joined: 05 Aug 2011 Posts: 6

Hallo MSD Freunde.

Ich möchte ein altes Backup von mir einspielen, welches sehr groß ist. Es scheint leider nicht zu funktionieren, obwohl ich mir sicher bin das es funktionieren sollte.
Es lief über Nacht und schien folgende Vorgehensweise zu besitzen:

Tabelle 1 löschen
Tabelle 1 anlegen... mit Datensätzen füllen.
Tabelle 2 löschen
Tabelle 2 anlegen... mit Datensätzen füllen.
Tabelle 3 löschen
Tabelle 3 anlegen... mit Datensätzen füllen.

Und an der Stelle kommt eigentlich eine weitere Tabelle. (Viele weitere). Aber anstatt diese abzuarbeiten fing MSD wieder bei Tabelle 1 an. Nach geschlagenen 10h Wartens konnte ich dies dann feststellen. Denn laut MSD wurden 91 Tabellen angelegt. Ich wurde stutzig als mehr Datensätze verarbeitet wurden, als eigentlich angegeben. Ich habe leider keinen Screenshot für euch, kann aber sagen das dies nicht nur beim MSD festzustellen war. Ein ähnliches Verhalten wieß auch phpmA auf. Ich weiß ihr seid nicht deren Supportforum aber da ich denke das ihr pma kennt, erzähl ichs auch kurz noch:
Mein multipart Backup in 200 Mb Dateien (gepackt), besteht aus mehreren Dateien. Also habe ich in pma angefangen ...part_1.sql.gz auszuwählen. Da die Dateien zu groß für die Scriptlaufzeit sind, wurden sie gesplittet. Jedes Mal wenn ein VOrgang fertig war, gibt pma aus, das nun beim nächsten Vorgang ab einer bestimmten Position weitergemacht werden soll. Ich habe nicht schlecht geguckt als dort beim circa 7ten Vorgang ein negatives Offset zu sehen war.
Denkt ihr es hat was mit der Dateigröße zu tun?
Sollte ich mal die unzippten sql's mergen und dann importen lassen?
Kann MSD sowas auch?
Was fällt euch dazu ein?

(Ja eventuell hätte das besser in "Fehler/Probleme" gepasst. Aber ich denke hier ists auch nicht all zu schlimm oder?)

MfG Ony

Posted: 2011-08-06, 14:05 (No subject)

PHP benutzt einen Zeiger, der auf die aktuelle Stelle in der entpackten Datei zeigt. Deiser Zeiger hat einen Wertebereich von ca. 2GB. Wenn die entpackte Datei größer ist und damit der Dateizeiger größer wird, gibt es einen interne Überlauf und der Zeiger fängt wieder bei 0 an. Das scheint hier bei Dir zu passieren.

Versuche das Backup lokal durch den Konverter von MySQLDumper zu schicken. Dies splittet das Backup in kleinere Teile auf, welche sich danach einspielen lassen sollten.

**knows MySQLDumper** Joined: 05 Aug 2011 Posts: 6

Aber es ist ja schon gesplittet^^
Die kleineren Teile sind gepackt circa 200MB jeweils groß.
Entpackt so um die 1 gb. Insgesamt sollten es mehr als 20gb entpackt sein. Wie gesagt sind diese 20 gb schon gesplittet + gepackt.
Sind also die 20gb schuld? Denn wenn du sagst das der Überlauf erst bei 2gb stattfindet können es ja nicht die einzelnen Dateien sein. Aber wie kann dann jemals ein Backup >2gb eingespielt werden? Vermutlich weil die Dateien ja gesplittet sind. Aber wieso geht es dann nicht bei mir^^

Ich freu mich schon über eine Antwort Smile

Posted: 2011-08-06, 15:57 (No subject)

Damit die Daten der gepackten Dateien gelesen werden können, müssen diese intern entpackt werden. Der Dateizeiger zeigt auf den Offset in der entpackten Datei. Er kann also auch dann überlaufen wenn die gepackte Datei eigentlich kleiner ist.
Deshalb empfehlen wir auch immer Splitgrößen zwischen 10 und 50 MB, um eben nicht in dieses Problem zu rennen.

**knows MySQLDumper** Joined: 05 Aug 2011 Posts: 6

Kann ich es wieder zusammenfügen und dann neu splitten? Irgendwie manuell?

Posted: 2011-08-06, 16:54 (No subject)

Äh ...

**knows MySQLDumper** Joined: 05 Aug 2011 Posts: 6

Aber mein Backup ist doch schon gesplittet? (ca 20 Dateien je 200 mb (Endung .sql.gz -> also gepackt)). Bevor ich es in mysqldumper neu splitten kann, muss es doch erst wieder eine Datei sein, stimmts?

Posted: 2011-08-06, 17:07 (No subject)

Wenn Du weiterhin immer Gegenfragen stellst anstatt einfach mal das auszuprobieren, was man Dir empfiehlt, werde ich Dir nicht mehr antworten wollen. Das nervt. Brick wall

Posted: 2011-08-06, 17:50 (No subject)

Oder einfacher: wenn Du noch Zugriff auf die originale Datenbank hast, mache ein neues Backup mit MySQLDumper, aber stelle die Multipartgröße auf 50 MB.