gzip gepackte mysql-dumps einspielen wirft Fehler aus

[Jörg]

Hallo,

ich sichere über ein wunderbares Script vom Raketenscripter meine mysql-DBs. Jetzt wollte ich eines davon über php wieder einspielen, das wirft aber einen fehler aus. Was mache ich falsch?

$db_host = 'localhost';
$db_user = '...'; // User der zu rettenden DB
$db_pass = '...'; // Passwort der zu rettenden DB
$db_name = '....'; // Name der zu rettenden DB
$file = '/path/dbxyz.sql.gz'; // die genaue Backupdatei (der sql-dump)

// Dann Backup  einspielen
system('/bin/gunzip -c ' .$file. ' | /usr/bin/mysql -u' .$db_user. ' -p' .escapeshellarg($db_pass). ' -h' .$db_host. ' ' .$db_name. ' ', $fp);
if ($fp==0) {
    echo "Daten importiert";
} else {
    echo "Es ist ein Fehler aufgetreten";
}

Gruß und schönen Heiligabend

Jörg

[sdfkvsdnlk]

Jetzt wollte ich eines davon über php wieder einspielen, das wirft aber einen fehler aus. Was mache ich falsch?

1. Du sagst nur, es würde ein "Fehler ausgeworfen", aber benennst den Fehler nicht, und hoffst jetzt, irgendwer möge eine Glaskugel mit direkter Verbindung zu deinem Skript haben.

2. Du verwendest ein Skript, das Fehlerausgaben unterdrückt bzw. durch ein nichtssagendes "Es ist ein Fehler aufgetreten" ersetzt, und hoffst jetzt, irgendwer möge eine Glaskugel mit direkter Verbindung zu deinem mysql haben.

system('/bin/gunzip -c ' .$file. ' | /usr/bin/mysql -u' .$db_user. ' -p' .escapeshellarg($db_pass). ' -h' .$db_host. ' ' .$db_name. ' ', $fp);
if ($fp==0) {
    echo "Daten importiert";
} else {
    echo "Es ist ein Fehler aufgetreten";
}

Mal abgesehen davon, dass dieses Skript jegliche hilfreiche Ausgabe von /usr/bin/mysql unterschlägt, scheint system() der Anleitung nach eine generell unbrauchbare Funktion zu sein, denn selbst wenn man die Ausgabe verwerten würde, man bekäme immer nur die letzte Zeile. Das kann manchmal zu wenig sein.

Verwende exec(), und verwende dort den Parameter output. mysql schreibt Fehler vermutlich in die Fehlerausgabe; möglicherweise hilft das Ergänzen von '2>&1' am Ende, um die Fehlerausgabe in die von exec() in output geschriebene Standardausgabe umzuleiten.

(Ob der Name fp für den Rückgabewert eine kluge Wahl ist – meist steht er als Abkürzung für filepointer, sowas wird hier aber nicht zurückgegeben –, ist wohl Geschmackssache.)

[Jörg]

Es lag daran, dass im gz-dump das Statement

USE Database blabla-name

drin stand.

Ich weiß aber nicht, wo im Script ich das verhindere. ich habe gelesen, dass man --database herauslassen soll. Das steht aber nirgends 😕

Wer kann helfen?

Jörg

[Raketenskripter]

Es lag daran, dass im gz-dump das Statement USE Database blabla-name drin stand.

Ich weiß aber nicht, wo im Script ich das verhindere.

Gar nicht. Das Skript ist dafür gemacht, alle Datenbanken bis auf definierte Ausnahmen ( information_schema, mysql und in meinem Testcase auch OSM ) zu sichern. Dann muss aber USE Database blabla-name im Dump stehen.

Auf deutsch: Es ist eigentlich das falsche Skript für Deinen „use case“.

Aber Dir kann dennoch geholfen werden:

Wenn Du nur eine Datenbank sichern willst, dann besetzt Du die übrigen Optionen, lässt das -B $databases natürlich weg auch die Zeilen 46, 48, 70 musst Du löschen.

In Zeile 11 ist das --add-drop-database dann obsolet:

moreDumpOptions=' --add-drop-table --allow-keywords --extended-insert=TRUE'; 

Dann setzt Du noch:

$database="DEINE_EINE_DATENBANK";

Uns sicherst mit dem angepassten Befehl in Zeile 56 Deine eine Datenbank.

$mysqldump_bin --host="${host}" --port="${port}" --user="${user}" --password="${passwort}" $moreDumpOptions $database | gzip -c > "${outFile}" 2>> "${logFile}" ;


Und wie von Geister Hand ist weder `drop database` noch `create database` noch `use database` im Dump.

[Jörg]

Frohe Weihnachten, Raketenscripter,

Auf deutsch: Es ist eigentlich das falsche Skript für Deinen „use case“.

Aber Dir kann dennoch geholfen werden:

Och menno...jezt hast du Dir soviel mühe gemacht. Danke Dir!

Aber in Wahrheit ist es genau das richtige Script für mich, denn auch ich will ca. 20 DBs auf einen Schlag dumpen.

Und die fehlerhafte Anwendung ist auch in Wahrheit nicht so dramatisch, weil in 99% aller denkbaren Importfälle müßte ich genau in die DB importieren, die auch gesichert wurde. Es war nur gestern in meinem speziellen Fall anders.

Als ich dann die Anweisung händisch heraus genommen und zurück gepackt habe, lief das auch prima.

Also alles in allem kann ich mit dem Ursprungsscript sehr gut leben, das läuft saugut jeden Tag durch, während mein parallel laufendes php-script mit demselben Zweck in maximal 25% aller Fälle erfolgreich läuft. Das liegt schlicht an der Serverperformance. Shellscripte laufen da wohl nahezu endlöos, php-scripte nicht.

Daher vielen dank für Dein "Weihnachtsgeschenk", ich freu mich darüber, aber ich nutze trotzdem, lieber weiterhin das schöne Ursprungsscript.

Feier noch schön und danke,

Jörg