Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Hallo!
Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.
dafür gibt es ein sehr gutes Tool ... nennt sich MySQL Dumper
ich habe aber gerade keinen Link auf Lager ... aber eben mal bei Yahoo zu googeln sollte ja kein Prob sein
Ich würde zunächst mal den Quellblog auf 2.0.5 aktualisieren. Das geht relativ flott, und die Chance, dass das das Problem löst, ist relativ hoch.
lokal wp2.0.5 deinstallieren, 2.0.2 installieren, datenbank importieren und auf 2.0.5 updaten ;)
vG
Arno
Das Problem ist ziemlich sicher Versionssprung bei MySQL. Version 5 scheint im geforderten Syntax strenger zu sein als die 4er. Hatte mit meinen Plugin deshalb auch schon meine Probleme.
Suche am Besten mal nach einen MySQL-Forum und stelle dort die Frage. Ich denke für die MySQL-Profis dürften sofort wissen woran es hapert.
Das Problem ist ziemlich sicher Versionssprung bei MySQL. Version 5 scheint im geforderten Syntax strenger zu sein als die 4er.
Nein, das Problem ist, dass das WordPressPlugin ein Leerzeichen zwischen die schließende Klammer und das Semikolon schreibt.
Das ist kein offizieller Syntax und deshalb knallt es da beim Einlesen mit MySQLDumper. Das wirft den internen Parser völlig aus der Bahn, denn er erkennt das Ende eines SQL-Befehls anhand der Zeichenkette );, die es hier aber nicht gibt.
So:
INSERT INTO `wp_categories` VALUES (31, 'webmaster', 'webmaster', '', 0, 3) ; <-- Leerzeichen
ist es falsch und so:
INSERT INTO `wp_categories` VALUES (31, 'webmaster', 'webmaster', '', 0, 3); <-- kein Leerzeichen
wäre es richtig.
Ein kleiner Fehler mit großer Wirkung. ;)
Das Problem ist dem ehemaligen Entwickler auch gemeldet worden, aber der fühlt sich nicht mehr zuständig und bis heute hat das keiner im WP-Plugin korrigiert. Dabei wäre das nur ein einzige winzige Stelle im Code, die zu ändern wäre.
Wäre das Leerzeichen weg, so könnte das per WP-Backup erstellte Backup problemlos mit MySQLDumper wieder eingespielt werden.
Das Problem ist dem ehemaligen Entwickler auch gemeldet worden, aber der fühlt sich nicht mehr zuständig und bis heute hat das keiner im WP-Plugin korrigiert. Dabei wäre das nur ein einzige winzige Stelle im Code, die zu ändern wäre.
Wenn Du's weisst, und das Plugin derzeit ohne Entwickler dasteht, übernimm Du diese Aufgabe doch und korrigiere das Plugin ;)
vG
Arno
Ich verbringe bereits nahezu meine gesamte Freizeit mit der Entwicklung und dem Support für MySQLDumper. Da verspüre ich nicht unbedingt Lust noch weiteren Support für andere Projekte zu geben. :-?
Ich wäre aber bereit die Stelle einmalig zu finden und zu korrigieren. Sende mir den Code des PlugIns an admin at mysqldumper.de und ich schaue mal rein.
Habs schon gefunden. ;)
In der Datei backuprestoreAdmin.php muss Zeile 104:
$sql_statements .= " \n" . $entries . implode(', ', $values) . ') ;';
ausgetauscht werden gegen
$sql_statements .= "\n" . $entries . implode(', ', $values) . ');';
Und schon klappt es künftig mit validen Backups. ;)
Wobei ich beim Durchsehen des Codes nun gesehen habe, dass das PlugIn die maximale Laufzeit von PHP-Skripten nicht berücksichtigt! Ist die Datenbank groß genug, so kann hiermit kein vollständiges Backup der Datenbank mehr angelegt werden, da das Skript in den Timeout rennt.
Daher empfehle ich lieber den MySQLDumper. Nicht aus Eigennutz, sondern um euch unvollständige Backups zu ersparen. ;)
Nein, das Problem ist, dass das WordPressPlugin ein Leerzeichen zwischen die schließende Klammer und das Semikolon schreibt.
Das ist kein offizieller Syntax [...]
Das wage ich zu bezweifeln. Wenn dem so wäre, müsste man bei folgender Eingabe ja einen Syntaxfehler bekommen:
SELECT 1+1 ;Das Leerzeichen ist ein "Internal Field Separator" (IFS), d.h. ein Zeichen, dass Syntax-Elemente voneinander trennt, und der darf normalerweise überall stehen. Das Semikolon zeigt das logische Zeilenende an und darf auch durch einen IFS abgetrennt sein.
Oder gibt es eine Stelle in der MySQL-Dokumentation, die etwas anderes behauptet?
Gut, meine Aussage "ist kein offizieller Syntax" nehme ich auch gerne zurück. Ich habe in der Doku weder etwas dafür noch dagegen gefunden.
Die Diskussion ist aber auch müßig, denn das ist nicht das Problem. ;)
Ohne meine Änderung von oben schreibt das Script pro Datensatz 2 unnötige Leerzeichen in das Backup, die rein gar nichts bewirken und einfach nur Speicherplatz verbrauchen. Bei 50.000 Datensätzen sind das schon 100.000 überflüssige Leerzeichen, die letzlich die Größe des Backupfiles unnötig vergrößern. Das verbietet sich eigentlich von alleine.
Abgesehen davon schreibt kein anderes Backupprogramm ein Leerzeichen zwischen die schließende Klammer der Insert-Anweisung und dem abschließenden Semikolon - auch das Konsolen-mysqldump nicht. Es macht schlichtweg keinen Sinn.
Und bitte - ich habe die Stelle gern gefunden und verbessert. Im Posting davor wurde ja danach gefragt.:wink:
Danke für die Hilfe Daniel.
Ich benutze den Dumper jetzt schon seit der ersten wirklich lauffähigen Version (war das noch 2005 oder doch schon 2006?) und empfehle ihn ausdrücklich. Vor allem sollte man Backups damit nicht nur einspielen, sondern auch erstellen. Ich habe damit auch bereits richtig große Backups > 100 MB problemlos einspielen können. Gehört bei mir zum Standard jeder Webpräsenz auf der eine Datenbank zum Einsatz kommt.
Ende des Werbetextes ;-)
Alles anzeigenGut, meine Aussage "ist kein offizieller Syntax" nehme ich auch gerne zurück. Ich habe in der Doku weder etwas dafür noch dagegen gefunden.
Die Diskussion ist aber auch müßig, denn das ist nicht das Problem. ;)
Ohne meine Änderung von oben schreibt das Script pro Datensatz 2 unnötige Leerzeichen in das Backup, die rein gar nichts bewirken und einfach nur Speicherplatz verbrauchen. Bei 50.000 Datensätzen sind das schon 100.000 überflüssige Leerzeichen, die letzlich die Größe des Backupfiles unnötig vergrößern. Das verbietet sich eigentlich von alleine.
Abgesehen davon schreibt kein anderes Backupprogramm ein Leerzeichen zwischen die schließende Klammer der Insert-Anweisung und dem abschließenden Semikolon - auch das Konsolen-mysqldump nicht. Es macht schlichtweg keinen Sinn.
Und bitte - ich habe die Stelle gern gefunden und verbessert. Im Posting davor wurde ja danach gefragt.:wink:
Jau, da gebe ich Dir völlig recht. Aber vllt. könnte man doch mit einer kleinen Regex doch sicherstellen, dass bei dieser seltsamen, aber anscheinend korrekten Syntax das Einlesen der Daten doch funktioniert.
Bzgl. Speicher sparen: Dann könnte man auch die (meisten) physikalischen Zeilenumbrüche weglassen. ;)
Hab mir übrigens den Dumper mal angeschaut, hat einen guten ersten Eindruck hinterlassen. Allerdings musste ich die erzeugte Datei zweimal entpacken.
Ach ja, a propos Timeout: Man kann den PHP-Timeout auch beliebig erhöhen (wenn PHP nicht im Safe Mode läuft): PHP: set_time_limit - Manual
Aber vllt. könnte man doch mit einer kleinen Regex doch sicherstellen, dass bei dieser seltsamen, aber anscheinend korrekten Syntax das Einlesen der Daten doch funktioniert.
Das habe ich zunächst überlegt, diesen Gedanken dann aber wieder verworfen. Unser Parser parst sehr unkonventionell (also nicht per RegEX), ist speziell auf SQL-Dumps ausgerichtet und dadurch sehr schnell (da kommt phpmyadmin nicht mit *g*). Hier eine weitere Überprüfung auf Leerzeichen einzubauen kostet in der Summe sehr viel Zeit und würde die Dauer einer Wiederherstellung verlängern. Und nur für ein einziges Programm, welches hier Leerzeichen einfügt, mache ich das nicht. Da stehen Kosten und Nutzen in keinem sinnvollen Verhältnis. Einfacher und effektiver ist es, wenn die WP-User den oben geposteten Bugfix in ihrem Script vornehmen.
Bzgl. Speicher sparen: Dann könnte man auch die (meisten) physikalischen Zeilenumbrüche weglassen. ;)
Nein, kann man nicht. ;)
Damit das Restore mit beliebig großen Backupdateien funktioniert und gleichzeitig das Zeitlimit berücksichtigt werden kann, liest der Dumper das Dump zeilenweise ein und nicht am Stück. Wenn keine Zeilenumbrüche enthalten wären, wäre das komplette Backup in einer Zeile und so würden zahlreiche Beschränkungen (Speicherlimit, Ausführungszeit, usw..) hier zum Exitus führen. Ich habe da so meine Erfahrungen. ;)
Ach ja, a propos Timeout: Man kann den PHP-Timeout auch beliebig erhöhen (wenn PHP nicht im Safe Mode läuft): PHP: set_time_limit - Manual
Du sagst es: wenn PHP nicht im safe_mode läuft, bzw. gibt es auch andere Möglichkeiten diesen Wert zu beeinflussen, auch wenn der safe mode aus ist.
Es gibt Server, da steht dort eine -1 drin und die Steurung erfolgt über ganz andere Stellen. Ich habe mich im Rahmen der Entwicklung intensiv mit Serverkonfigurationen und Limits beschäftigt. Da erzählst Du mir nichts Neues. ;)
Der Dumper funktioniert aber nahezu unter jeder Serverkonfiguration. Ferner halte ich es nicht für sinnvoll einer vom Hoster gesetzten Einschränkung entgegegenzuwirken.
Der Dumper nähert sich intelligent an die zur Verfügung gestellten Resourcen an und stellt sich automatisch auf die Geschwindigkeit des Servers ein. Das Funktionsprinzip ist so wie es ist erprobt und hat sich in der Praxis perfekt bewährt.
P.S.: Wieso bekomme ich bei Antworten keine Benachrichtigungsemail obwohl das in meinem Profil eingestellt ist? Ist das hier generell deaktiviert?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
