Von MySql 4.1.21 auf MySql 4.1.13 Daten Restore

[Indextrader]

Hallo ihr Lieben

Ich beisse mir schon wieder seit Tagen die Zähne aus, was für euch sicher ein Klax ist

Ich möchte gern die Daten aus der DB MySql 4.1.21 (php 4.4.4) die auf einem shared Server liegt in die MySql 4.1.13 (php 4.4.0) pumpen, die auf einem eigenen decicated Server liegt.
Habe mir also ein Backup gezogen und dachte mir das ich es mal schnell Restore, erhalte baer ständig Fehlermeldungen.

Got a packet bigger than 'max_allowed_packet' bytes oder ständig
MySQL server has gone away

Habs bestimmt schon 100 x versucht, aber die DB bricht immer an der selben Stelle ab.
Habe im Netz gefunden, das man beim Export und Import die verschiedenen Versionen der DB in Myadmin abstimmen könnte, finde aber keine Möglichkeit was passendes auszuwählen.

Alternativ zu Myadmin habe ich noch SQLyog

[oxpus]

Mit welchem Programm hast Du denn das Backup erstellt und willst es wieder herstellen? Mit phpmyadmin?
Am besten geht das immer noch mir mysqldumper, der extra darauf programmiert wurde, durch ständigen Selbstaufruf Timeouts und Abbrüche zu umgehen.
Selbst megagrosse Backups können so wieder problemlos eingespielt werden.

[Indextrader]

Moin Oxpus

Mit welchem Programm hast Du denn das Backup erstellt und willst es wieder herstellen?

Zuerst habe ich es mit Myadmin gemacht.
Dann habe ich es mit dem MySqlDumper versucht, er arbeite locker eine Stunde und dann bricht er ab.

Ich möchte mir die Datenbank vom shared Server auf den dedicated Server ziehen, damit ich das Script dann dort laufen lassen kann.

[oxpus]

Dann habe ich es mit dem MySQLDumper versucht, er arbeite locker eine Stunde und dann bricht er ab.

Das ist ungewöhnlich, daß er überhaupt so lange arbeitet.
Wie groß ist denn die Datenbank?
Selbst bei meiner 70 MB grossen Datenbank braucht der mysqldumper nur weniger als 2 Minuten.

Bricht der Dumper dabei mit einer Fehlermeldung ab oder bleibt die Seite nur (weiß) stehen?
Das solltest Du dann auch mal dem Support für den Dumper melden, vielleicht ist das ein Fehler im Programm.

Ansonsten könntest Du auch mit mysqldump auf der Shell selber versuchen, die Datenbank zu sichern, sofern Du Root-Zugriff hast (bei shared Servern eher selten).

Aber das der Dumper versagt und überhaupt so lange läuft...

[Indextrader]

Ok scheint an der Tabelle zu liegen, die die Attachments verwaltet. Dort bleibt der Dumper auch immer hängen, irgendwann nach etwa 60min bricht er ab und schreibt ins Log Lost Connection to MySql.

Habe beim Backup diese Tabelle weggelassen und dann macht der Dumper den Restore einwandfrei.
Ist ein wirklich super Teil

Allerdings verstehe ich nicht, wie das Script inkl der Attachments einwandrei auf dem Server laufen kann und wenn ich von der DB ein Backup mache, dieses nicht komplett auf den anderen Server übertragen kann.

Aber was solls, die Attachments sind nicht wichtig.

Danke und ein wunderschönes WE

[oxpus]

Versuch doch mal, die Tabelle zu reparieren, bzw. zu prüfen/optimieren.
Vielleicht ist ja ein Fehler drinnen, der damit ausgebügelt wird...

[Indextrader]

Auf die Idee bin ich auch schon gekommen, hatte baer nichts gebracht.
Naja vielleicht läuft mir irgendwann eine LKösung über den Weg, wenn ich gar nicht mehr damit rechne.

Ansonsten klappt es ja nun

[DSB]

Got a packet bigger than 'max_allowed_packet' bytes

Dieses Problem tritt auf wenn Binärdaten direkt in der Datenbank abgelegt werden (was meiner Meinung nach einer Vergewaltigung des DB-Systems gleich kommt *g*).

Wenn der MySQL-Server z.B. so eingestellt ist, dass er Queries bis zu einer maximalen Größe von 2 MB annehmen darf und in den Attachements eine Datei liegt, die 2,1 MB groß ist, dann verweigert der MySQL-Server die Ausführung des entsprechenden Insert-Befehls.
Das gleiche Problem kann auftreten wenn man beim Backup erweiterte Inserts eingestellt hat. Hier werden dann alle Datensätze einer Tabelle in einen einzigen Query geschrieben, so dass die maximal erlaubte Größe auch schnell überschritten wird. Deshalb rate ich immer von erweiterten Inserts ab.

@Indextrader
- Mach ein neues Backup per MySQLDumper - dann wird der Import sehr wahrscheinlich auch klappen.
- Oder schicke das Backup im Dumper durch den Konverter. Der Konverter löst erweiterte Inserts in normale Inserts auf, so dass der Import danach klappt, wenn es nicht an der Größe eines einzelnen Datensatzes liegt.

[oxpus]

Wenn der MySQL-Server z.B. so eingestellt ist, dass er Queries bis zu einer maximalen Größe von 2 MB annehmen darf und in den Attachements eine Datei liegt, die 2,1 MB groß ist, dann verweigert der MySQL-Server die Ausführung des entsprechenden Insert-Befehls.

Im Grunde ist das richtig aber auch nicht die ganze Wahrheit:
Binäre Daten werden nicht direkt in der Tabelle abgelegt, sondern von dort aus verlinkt.
Wenn die Datenbank entsprechend eingestellt ist, werden somit binäre Daten getrennt vom INSERT-Statement betrachtet und können "beinahe" beliebig groß sein. Ausser der Upload selber ist dabei nicht mehr möglich.

Binäre Daten werden aber durch den INSERT-Befehl immer komplett eingelesen, das kann dann schon zu dieser Fehlermeldung führen.

Nur:
Wenn diese Daten bereits in der alten Datenbank stecken, ist entweder auf der neuen Datenbank der Wert hierfür niedriger eingestellt (dann muss auf den ein oder anderen Datensatz verzichtet werden, sofern man diesen nicht ändern kann) oder die INSERT-Statements sind wirklich zu groß, worauf ich eher tippe, da sie als "erweiterte INSERTS" erstellt wurden (Ich habe nie begriffen, wozu diese Möglichkeit wirklich Sinn machen soll).
Hier hilft dann der Dumper weiter, alles andere ist nicht mehr möglich.

Oder eben mysqldump auf der Root Shell. Dieser MySQL-Befehl sichert wirklich alles und ohne Rücksicht in einer Datei zusammen und kann das auch wieder in einer neuen Datenbank herstellen.
Details zu mysqldump sind hier zu finden: http://dev.mysql.com/doc/refman/5.1/de/mysqldump.html

[DSB]

[quote="oxpus";p="75538"]

Wenn der MySQL-Server z.B. so eingestellt ist, dass er Queries bis zu einer maximalen Größe von 2 MB annehmen darf und in den Attachements eine Datei liegt, die 2,1 MB groß ist, dann verweigert der MySQL-Server die Ausführung des entsprechenden Insert-Befehls.

Im Grunde ist das richtig aber auch nicht die ganze Wahrheit:
Binäre Daten werden nicht direkt in der Tabelle abgelegt, sondern von dort aus verlinkt.[/quote]
Ich habe allgemein gesprochen und mich nicht nur auf das phpbb bezogen. Es gibt in der Tat einige Systeme, die die Attachements direkt binär in der Datenbank ablegen (dies ist z.B. die Standardeinstellung beim vBulletin).
Beim phpBB ist das aber nicht so. Insofern war mein Posting etwas mißverständlich formuliert - da gebe ich Dir Recht.

[oxpus]

Ich bezog mich aber mit meinem Posting NICHT auf ein phpBB, sondern auf die in der Datenbank möglichen BLOB-Felder, die binäre Daten beinhalten können.
Und es ist wirklich so, daß die Felder "technisch" gesehen nur einen Link zum eigentlichen Inhalt beinhalten, sonst würde es die DB schnell sprengen können, der Inhalt, also die binäre Datei aber in Wirklichkeit woanders.

Leider wird aber dann per "Krücke" der Inhalt als binärer Content mittels SELECT, bzw. INSERT/UPDATE behandelt, als wäre es ein "echter" Feldinhalt, was dann zwangsweise zu Problemen führen kann.
Hier sind Datenbanksysteme, wie z. B. die von ORACLE deutlich weiter, naja, die kosten ja auch dafür eine Menge Geld...

Und das vB lässt sich nach meinem Wissen einstellen, wie Attachments abgelegt werden.
In der Datenbank wollte ich das nicht haben, belastet diese nur unnötig und damit auch die Performance.
Die Attachment-Lösung des phpBB ist hier deutlich besser, da sie unabhängig der Datenbank die Dateien behandelt und man auch bei Bedarf "manuell" in die Dateiflut eingreifen kann.