MySQLDumper Problem mit zlib

[PatrickS3]

Ich habe da ein Problem mit dem MySQLDumper in Verbindung mit der Wiederherstellung von Datenbanken.

Der MySQLDumper speichert Datenbank Backups als gz Archiv ab.

Wenn ich nun auf der Diskstation DS 410 (Firmware siehe Signatur) versuche die Datenbank wiederherzustellen, bricht die Wiederherstellung ab und es wird nichts hergestellt.

Nach ein wenig forschen habe ich rausgefunden, dass es an einer fehlenden zlib Installation liegen könnte.

Also das Backup (ganz normal mit 7zip unter Windows im Netzlaufwerk) entpackt und siehe da, dann kann ich die Datenbank wiederherstellen.

Nun das eigentliche Problem:
Unter "Bedienfeld / Webdienste" kann man einzelne Module für PHP aktivieren und dort ist bei zlib ein grüner Haken, was für mich bedeutet, dass es eigentlich installiert sein sollte, oder?

Hat jemand schon einmal so ein Problem gehabt und dafür evtl. eine Lösung?

Ach ja, MySQLDumper Version 1.24.4.

Gruss Patrick

 

[jahlives]

gz-Archive sollten auf der DS out-of-the-box problemlos möglich sein. Vielleicht noch ein anderes Problem mit mymsql-dumper. Auf der DS gibt es jedoch ein mysql-Helferlein, welches aus Tabellen und Datenbanken sql-Backup-Files erzeugen kann. Das Teil funzt problemlos und backuppt meine mysql-Datenbanken regelmässig

cd /volume1/@db_backup
/usr/syno/mysql/bin/mysqldump -uroot -pMEIN_PW NAME_DER_DB > ./file.sql

 

[PatrickS3]

Danke für die Info.

Kann man die Unterstützung von zlib irgendwie testen, also ob es läuft?


Vielleicht sollte ich mal die Macher vom MySQLDumper anschreiben? Denn auf meinem normalen Webspace funktioniert der MySQLDumper ohne Probleme.

 

[jahlives]

Versuch doch ein Archiv zu entpacken

 

[PatrickS3]

So einfach. Aargh.

 

[niesner]

Ich habe das gleiche Problem. Da für unser gemeinsames Problem offenbar noch niemand eine Lösung gefunden hat (auch nicht im Forum von MySQLDumper), habe ich mich selbst hineingekniet und nach einem von meiner besten Ehefrau von allen misstrauisch beobachteten "gemütlichen" gemeinsamen Abend vor dem Fernseher mit dem Notebook auf den Knien unter intensiver Verwendung von var_dump und echo die wahrscheinliche Ursache gefunden:

Es dürfte an der im Apache-Webserver der Synology Diskstation verwendeten zlib-Version (1.2.5) liegen, bei der die php-zlib-Funktion gzseek entgegen der aktuellen Dokumentation [int gzseek ( resource $zp , int $offset [, int $whence = SEEK_SET ] )] bei meinen Versuchen den Dateizeiger nicht vom Dateianfang, sondern immer relativ von der aktuellen Zeigerposition weg setzt und damit natürlich jedesmal den Zeiger für MySqlDumper falsch positioniert. So kommt es zu den genannten Fehlfunktionen. Das geschilderte Verhalten wäre aber ein grober Bug, der eigentlich auch anderen auffallen hätte müssen.

Der Befehl gzrewind funktioniert glücklicher Weise einwandfrei und setzt den Dateizeiger wieder auf den Dateianfang, sodass nachfolgende gzseek-Befehle mit absoluter Einsprungadresse wieder den richtigen Einsprungpunkt setzen sollten.

Ich hatte geglaubt, bereits einen Workaround zu haben, leider hat sich dieser bei neuerlichem Test als doch nicht funktionstüchtig erwiesen.

Da ich bei einem von mir eingefügten gzrewind($restore['filehandle']) in der restore.php (Zeile 112) beim Abarbeiten über einen Wert von $restore['offset'] von 23483 nicht hinauskomme (es wird dann beim wiederholten Seitenaufruf einfach nicht mehr und bleibt beim gleichen "Höchst"-Wert), habe ich entweder den Programmablauf noch nicht richtig gedeutet oder gibt es noch ein anderes Problem, ev. mit gztell() ...

Bis zu einer Lösung kann man sich dahingehend behelfen, dass man zwar gzkomprimierte Backups erzeugt (sind ja wesentlich platzsparender), aber das Backup-File im Work-Verzeichnis von MySQLDumper vor dem Restore mit einem Packer/Entpacker (z.B. mit 7-ZIP) entpackt (sollte dann auf .sql enden). Diese unkompromierte Datei kann MySQLDumper einwandfrei verarbeiten.

Gleich unkomprimiert ohne Gzip-Kompression arbeiten geht natürlich auch: -> in der Konfiguration unter Allgemein die GZIP-Kompression ausschalten.