phpmyadmin 4.6.4 ist buggy – nicht für Sicherungen verwenden !

Ich hatte heute die Aufgabe, die Daten eines WordPress-Blogs von der MySQL-Datenbank eines Hosting Providers zu sichern und den Blog dann auf eine neue Datenbank bei einem anderen Provider umzuziehen. Dabei hat ein übler Bug in der phpMyAdmin-Version 4.6.4 etliche meiner Nerven verschlissen:

Auf Exports von Tabellen mit Kommentaren oder Spalten mit bestimmten HTML-Inhalten kann man sich bei der aktuellen Version (Stand 03.10.2016) leider nicht verlassen; der nachfolgende Import scheitert unter Umständen - vermutlich wegen einer fehlenden oder fehlerhaften Maskierung von Anführungszeichen.

Es dauerte aber eine ganze Weile, bis ich anfing, der Exportfunktion von phpMyAdmin zu misstrauen - vor allem, weil mir bei dem Provider keine Datenbank-Logs zur Verfügung standen. Ich konnte den Fehler aber an einer reduzierten "posts"-Testtabelle der WordPress-Installation nachvollziehen; der Export und nachfolgende Import schlägt mit der Version 4.6.4 reproduzierbar fehl - in meinem Fall sogar mit einem internen Server-Error.

Gott sei dank war die alte Datenbank noch nicht gelöscht! Ich konnte den Export/Import-Vorgang mit der auf die Schnelle installierten phpMyAdmin-Version 4.4.15.8 anschließend anstandslos und fehlerfrei durchführen.

Solche Bugs können üble Folgen haben, wenn man nach einer "Sicherung" naiverweise den alten Datenbank-Zustand löscht, ohne vorher an einer anderen Datenbank den Reimport getestet zu haben. Auch für phpMyAdmin gilt bei Sicherungen die alte Regel:
Immer erst die ganze Kette zur Restaurierung testen, bevor man irgendetwas löscht!

Dennoch: So ein Bug ist wirklich übel! Ich bin ein wenig sauer .... im Nachhinein fand ich dann unter github folgende Bug-Einträge:
https://github.com/phpmyadmin/phpmyadmin/issues/12086
https://github.com/phpmyadmin/phpmyadmin/issues/12453
Der erste davon wurde geschlossen, obwohl er offenbar immer noch oder wieder vorhanden ist.

phpMyAdmin – Versionscheck – Firewalls

Gerade arbeite ich an einem Projekt, in dem die Anzahl der Tabellen auf einem MySQL-Server mit mehreren Datenbanken rasant steigt. Zur Verwaltung nutze ich u.a. phpMyAdmin in der Version 4.0.1. Nun haben wir kürzlich die ersten Testsysteme auf einen größeren Server mit einer restriktiven Firewall verlagert. Danach fiel mir auf, dass phpMyAdmin unmittelbar nach dem Login für ca. 1 Minute nicht reagiert, wenn man sich die Tabellen der angelegten Datenbanken auflisten lassen will. Irgendwann kommt dann jedoch die erwartet Übersicht über die Tabellen. Und danach funktioniert auch alles wieder so rasch wie erwartet.

Diese initale Verlangsamung von phpMyAdmin - besser dieses initiale Hängenbleiben - machte mich total nervös. Zumal dieses Verhalten für mich neu war, und ich es auf anderen Systemen bislang nicht beobachtet hatte. Wartezeiten von 1 Minute sind während hektischer Entwicklungsarbeiten nicht tolerierbar. Das beschriebene Verhalten tritt nämlich immer wieder auf, wenn die maximale Inaktivitätszeit, die in phpMyAdmin oder in den php-Einstellungen des Servers gesetzt ist, abläuft und man sich erneut einloggen muss. Und dann will man natürlich keine zusätzliche Verzögerung bei der Abfrage nach den vorhandenen Tabellen im Minutenbereich erleben.

Also hieß es: Logs einsehen. Die Firewall zeigte denn auch tatsächlich, dass der Server, auf dem phpMyAdmin installiert war, versucht, eine HTTP-Verbindung zu der Adresse 216.34.181.97 aufzubauen. Solche aktiven HTTP- Verbindungen in die weite Welt werden von unserem Server aus aber nicht zugelassen.

Ein Nachforschen mit "whois" zeigt, dass diese Adresse möglicherweise unter der Hoheit von SourceForge steht. Oder aber etwas mit phpmyadmin.net zu tun hat. Ok - für einen Test mal die Firewall-Regeln abändern und die Verbindung vorübergehend zulassen. Und siehe da:

Keine initiale Verlangsamung mehr, sondern ein gewohnt spritzig reagierendes phpMyAdmin. Reproduzierbar! Dass phpMyAdmin nach dem Startup so langsam reagierte, rührte also daher, dass das Programm die genannte HTTP-Verbindung erwartete, aber nicht bekam - und den Verbindungsversuch in einer solchen Situation vermutlich mehrfach startete, bis es schließlich aufgab.

Es ergeben sich mehrere Fragen:

Frage 1: Wozu dient dieser Verbindungsversuch von phpMyAdmin ?
Vermutlich(!) zur Abfrage von Update-Informationen (neue Versionen, ...). Siehe hierzu den Informationsbereich auf der ersten Seite nach dem Öffnen von phpMyAdmin. Dort wird dargestellt, welche Version man gerade im Einsatz und ob es eine neuere gibt. Aber wer weiß .... in diesen Zeiten .... Ich habe es jedenfalls nicht persönlich im Code überprüft.

Frage 2: Gibt es einen Parameter, um das abzustellen ? Oder muss man mit einem initial sehr langsamen phpMyAdmin hinter einer Firewall leben ?
Nein, muss man nicht - und ja, es gibt einen Parameter. Siehe :
http://wiki.phpmyadmin.net/pma/Config#VersionCheck

In meiner Situation half es demzufolge, in der Datei "config.inc.php" folgende Einstellung einzufügen:

$cfg['VersionCheck'] = false;

Das fand ich dann doch sehr beruhigend. Und es löste mein Problem - die http-Anfrage findet danach nicht mehr statt. Und phpMyAdmin läuft dann trotz restriktiver Firewall-Einstellungen performant.

Ich habe das Thema auch im phpMyAdmin-Bereich unter "Stackoverflow" angesprochen.
http://stackoverflow.com/questions/18766123/required-but-not-granted-http-access-to-216-34-181-97-slows-phpmyadmin-down
Wurde wirklich sehr schnell beantwortet. Das Verhalten wurde von einem interessierten Zeitgenossen bestätigt. Dort kam dann noch der Tipp, dass man die Abfrage auch über einen Proxy abarbeiten kann. Siehe
https://phpmyadmin.readthedocs.org/en/latest/config.html#cfg_VersionCheckProxyUrl
Danke hierfür an M. Delisle.

Abschließend bleiben folgende Fragen an die phpMyAdmin-Entwickler offen:
Könnte man das Thema mit dem Versionscheck nicht auch anders lösen? Wieso muss diese Abfrage überhaupt automatisiert ablaufen? Und wenn schon - warum nicht dezent und asynchron im Hintergrund (Ajax) mit Einstellungen, die den User nicht blockieren ?

Ich bin daher schon gespannt auf die nächste Version dieses wichtigen und nützlichen Tools.