Beiträge von DSB

Zitat von Tietoh

PS: "MySQLDumper" begrüßt mich online mit "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)".

Seit Deiner letzten Benutzung haben sich schlichtweg die Datenbank-Zugangsdaten geändert. Rufe einfach http://www.deineDomain.de/DeinDumperVerzeichnis/install.php auf und gib die jetzt richtigen Zugangsdaten an. Danach ist alles wie vorher.

Zitat von joker

versuche jetzt den Upload in 1.000er Schritten

Genau dieses manuelle Gefrickel kannst Du Dir mit MySQLDumper ersparen. Das kann er für Dich übernehmen. Du brauchst lediglich das Backup per FTP in den Ordner mysqldumper/work/backup laden, wählst die Datei zur Wiederherstellung aus, lehnst Dich zurück und schaust zu, wie der Dumper das Backup schrittweise einspielt. Vielleicht guckst Du ihn Dir doch einmal an. :-D

Um Umlautprobleme zu vermeiden und damit er Dir einen schönen Fortschrittsbalken anzeigt, empfehle ich, dass auch das Backup selbst bereits mit MySQLDumper gemacht wird. Natürlich spielt er auch valide SQL-Dumps andere Programme ein, aber Umlautsicherheit und Fortschrittsbalken gibt es nur wenn das Backup von ihm selbst stammt, da er diese Informationen als Kommentare mit im Backup ablegt und beim Einspielen auslesen kann. Bei Fremdbackups gibt es diese Informationen natürlich nicht.

Natürlich ist das jetzt Eigenwerbung, da der Dumper von mir selbst stammt, aber wenn Anwendern so Arbeit erspart wird und das Skript als Freeware für jedermann zur Verfügung steht, halte ich den Hinweis für gerechtfertigt.
Falls die Moderatoren hier das anders beurteilen, dann bitte ich um Löschung meines Posts.

Zitat von mastermind

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.

Zitat

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. ;)

Zitat

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?

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:

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. ;)

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.

Zitat von flash

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:

Zitat

INSERT INTO `wp_categories` VALUES (31, 'webmaster', 'webmaster', '', 0, 3) ; <-- Leerzeichen

ist es falsch und so:

Zitat

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.

Mit der brandneuen Version von MySQLDumper (Version 1.22) wird nun im Backup selbst die Information hinterlegt in welchem Zeichensatz das Backup erstellt wurde.

Beim Wiedereinspielen mit MySQLDumper wird diese Information wieder ausgelesen, so dass Umlautprobleme beim Dumper nun der Vergangenheit angehören. :-P

Wenn Du einen MySQL-Server > 4.1 hast: nimm zum Sichern und Einspielen MySQLDumper Version 1.21b12 ( MySQLDumper - Download - hole Dir die aktuelle Version ganz unten) und Du bist sorgenfrei, da er bei beiden Aktionen die Verbindungskennung intern automatisch uaf utf8 stellt..

Zitat von Xooyoo

Das Problem bei der DB Sicherung ist ganz einfach dies:
Der von WP verwendete Zeichensatz, das ist normalerweise der "iso-8859-1".

Der von WP verwendete Zeichensatz hat damit nichts zu tun. Es geht beim Sichern um andere Zusammenhänge.
Lies meinen Artikel mal. Da steht das genau beschrieben.

Hey cool, den Artikel habe ich gestern abend erst veröffentlicht. Der ist also noch warm und schon verlinkt. ;)
Ich finde das einfach nur Klasse wie das im Netz alles so funktioniert mit dem Informationsaustausch. Vielleicht hilft meine Darstellung ja tatsächlich dem ein oder anderen diesen Sachverhalt besser zu verstehen.
Ich wünsche allen allzeit korrekte Umlaute. :-D

Zitat von efriedrich

Danke auch für den Tipp SQL-Dumper, allerdings habe ich hier bisher nur eine Import-Funktion gefunden, bei der ich vorher die Tabelle angeben muss, in die ich importieren will. Das ist aber nicht das was ich brauche, ich möchte ja die Tabellen einfach zusätzlich in die Datenbank importieren. Hast du da noch einen Tipp oder soll ich mich mal an das Forum von SQL-Dumper wenden?

Cool, Du hast eine Funktion entdeckt die wir gar nicht programmiert haben. ;)
Wo hast Du denn die Info entdeckt?

Welche Tabellen angelegt werden steht doch im Backupfile. Das kann man nicht vorgeben.
Du musst lediglich die Datenbank auswählen (linkes Drop-Down-Menü), in die das Backupfile eingespielt werden soll.