Wahnsinn! Irgendwie bin ich auf die Idee gekommen, genau jetzt einen Umzug meiner Mysql-Datenbank von der verrufenen Version 4.0 auf die neuere 5.0 zu versuchen.

Auf meinem 1und1-Plätzchen lief ja Mysql 4.0. Und ich wollte schon seit einiger Zeit eine neuere Datenbank haben, um auch mal Drupal 6 auszuprobieren. Auch für meine 5er-Version laufen einige Module schon nur noch mit einer 5er-Mysql, und die Module will man ja auch mal testen können. Ebenso gibt es noch viele andere schöne php-Spielzeuge, die immer eine 5er-Datenbank haben wollen, wenn ich sie mal installieren will. Ausserdem ist 5 einfach neuer als 4. Und ausprobieren will ich so einen Umzug halt auch mal.

Da ich bei http://www.1und1.de nur eine 4er-Mysql habe und eh schon mal von 1und1 wegwollte, hab ich schon oft die Tarife und Ausstattung von http://www.hosteurope.de, http://www.df.eu und http://www.all-inkl.com verglichen. Eigentlich bieten sie alle das, was ich brauche, und noch dazu etwas billiger als 1und1. Andererseits läuft 1und1 bei mir eigentlich ohne Probleme. Man muss zwar erst ein paar Tricks, Eigenheiten und Anpassungen kennen lernen, aber nach allem, was man so liest, ist das bei anderen Anbietern auch so. Und so zögerte ich doch lange mit einem Umzug zu einem neuen Anbieter, der Aufwand für eine neuere Datenbank und ein paar Cent Ersparnis schien mir doch immer zu groß.

Die Entdeckung

Dann aber fand ich zufällig im Forum von http://www.drupalcenter.de einen Eintrag. Da erzählte jemand, dass man die 4er-Datenbank von 1und1 einfach löschen könne und dann wieder eine neue 5er-Mysql anlegen kann. Aha! Hatte ich damals bei der Ersteinrichtung etwa sicherheitshalber die ältere 4.0 gewählt? Der Eintrag klang vielversprechend und einfach. Also durchsuchte ich das Netz nach Backup- und Umzugsanleitungen. Hab schliesslich keine Ahnung von Mysql.

Informationen

Ich fand dann diese Warnhimweise: Erstens ist meine 4.0-Mysql scheisse, buggy, problemanfällig und sowieso hoffnungslos. Na klasse. Und zweitens gibt es beim Umzug das große große Problem mit den Umlauten und der Zeichenkodierung. Ha, dachte ich. Das kenn ich schon! Das Problem lernte ich mal kennen, als mein Linux von latin1 auf utf8 umstellte und ich alle meine latex-Dateien ändern musste. Dann gibt es das Problem mit varbinary und binary, das ich nicht verstanden habe. Und viele Berichte findet man über Datenverluste. Alle eindringlichen Apelle aber lauten: Daten sichern und nicht nervös werden! Eventuell googlen und dann klappt es schon.

erste Versuche

Also hab ich erst mal meine Datenbank gesichert. Mit dem bei 1und1 vorhandenen phpmyadmin, obwohl ich all die Konfigurationmöglichkeiten nicht verstehe, und mit dem Drupal-Modul http://drupal.org/project/backup. Ich hab mir auch das Ergebnis mal angesehen und mit meinen rudimentären Sql-Kenntnissen festgestellt, das die Backup-Datei eigentlich nur aneinandergereihte Sql-Befehle darstellen, um die Datenbank wieder aufzufüllen. Also kann man das im Notfall auch von Hand und mit viel zeitlichem Aufwand erledigen, verloren ist so in jedem Falle nichts!

Ich wollte noch nichts überstürzen und hab erst mal für mein Linux einen Apache-Server, eine Mysql-5, php5 und phpmyadmin installiert. Das geht schnell und einfach. Jetzt wollte ich mein Backup hier lokal einspielen und sah das erste Problem: für phpmyadmin ist das Backup einfach viel zu groß! Noch mal online bei 1und1 überprüft und es war klar: auch dort ist mein Backup zu groß, so kann man die Daten nicht wieder einspielen!

MySQLDumper

Eine neue Google-Suche fand dann http://www.mysqldumper.de. So wie ich es verstanden hab, spaltet die Software das Backup wohl in viele kleine Häppchen, die dann tatsächlich wieder eingespielt werden können. Und alle Erfahrungsberichte dazu waren eigentlich sehr positiv und es sollte einfach und sicher gehen. Ein Forum zu der Software erklärt viele Fragen, auch das nun für mich schon berühmte Umlaut-Problem.

MySQLDumper ist sehr schnell und einfach installiert. Damit habe ich ein neues Backup erstellt, ganz nach den voreingestellten Vorgaben und Vorschlägen. MySQLDumper hab ich dann noch lokal installiert, auch das ging gut. Und dann hab ich lokal mein Backup eingespielt. Das dauert recht lang. Am Ende kann man dann das Ergebins überprüfen und siehe da: das Umlaut-Problem war da!

das Umlaut-Problem

Jetzt ging es den Support-Foren, Blogs und anderen Google-Treffern an den Kragen: Was sollte ich tun? Eigentlich heißt es überall, man solle die Mysql-4er-Backupdatei mit der Zeichenkodierung latin1 mit einem Texteditor einfach als utf8 speichern und dann problemlos einspielen können. Aber da gab es bei mir zwei Probleme. Einmal hieß die Zeichenkodierung bei mir german1, so hat MySQLDumper es festgestellt und vorgeschlagen. Und über diese Kodierung findet man bei Google fast nichts. Und dann sagten meine Texteditoren Gedit und Kwrite, dass es sich doch eigentlich schon um eine utf8-Datei handele. Neues Speichern mit definitiver utf8-Kodierung brachte gar nichts. Ebenso wenig brachte das Umkodieren mit dem Terminal-Tool iconv, weder mit latin1 noch mit utf8 als Angabe für die Ursprungsdatei. Ich hab auch versucht, nur das ungezippte Backup in allen Kodier-Varianten einzuspielen, nichts half.

Bis mir dann eine Idee kam: Einzig an der seltsamen Kodierung german1 der Original-Backup-Datei hatte ich noch nicht herumgeschraubt. Also erstellt ich online ein neues vollständiges Backup, änderte aber diesmal in MySQLDumper die Kodierung auf latin1. Das Ergebnis war ernüchternd, auch diese Backup konnte ich nicht korrekt auf meinem lokalen Server einspielen. Und jeder normale Texteditor sagt wieder, dass es sich doch eigentlich schon um eine utf8-Datei handelt.

Aber ich bemerkte dann das hier: Die jeweils erste Zeile der Backupdateien lautet u.a.

php:1.22:latin1:4.0.27-max-log:1000001:::latin1:EXTINFO
php:1.22:gesamt:4.0.27-standard-log:1000001:::german1:EXTINFO

Schau an. Da stehen ja die ominösen Kodierungen german1 und latin1, eingetragen in der Backup-Datei. Kann ich hier nicht einfach mal utf8 eintragen? Aber wie? utf8 oder utf-8 oder noch anders? Jetzt also hab ich mal mein missglücktes lokales Backup aus meiner lokalen Mysql-5-Datenbank mit meinem lokal installierten MySQLDumper erneut exportiert, aber diesmal als utf8. Und siehe da, diese sonst natürlich nutzlose und völlig Zeichenkodier-verkorkste Datei zeigt mir zumindest den erwarteten Header

php:1.22:utf-backup:5.0.32-Debian_7etch6-log:1000001:::utf8:EXTINFO

Also hab ich nun die Original-latin1-Backupdatei, die alle meine Editoren eh schon längst zu einer utf8-Datei erklärt haben, einfach in der ersten Zeile mit den Buchstaben utf8 versehen. Und nun konnte ich sie lokal korrekt einspielen. Auch MySQLDumper zeigte nun im Wiederherstellungs-Dialog die Kodierung utf8 an!

endgültiger Umzug der 1und1-Datenbank

Jetzt also ging es an das Online-Original. Ein MySQLDumper-Backup hatte ich ja bereits und die Datei mit geändertem Header konnte ich per ftp wieder in das passende MySQLDumper-Verzeichnis zurückspielen.

Kurz überlegt, und dann hab ich beherzt meine Mysql-4.0-Datenbank bei 1und1 gelöscht. Das Ziel war ja, sie danach als 5.0 wieder zu aktivieren. Jetzt musste ich warten. Der 1und1-Dialog zeigte "Die Datenbank wird gelöscht" an. Stundenlang. Eine neue Datenbank konnte ich nicht anlegen. Irgendwann loggte ich mich mal aus und gleich wieder ein. Und nun war der Dialog zum Anlegen einer neuen Datenbank frei. Vielleicht hätte man sich direkt ausloggen sollen und hätte sich Stunden des Wartens gespart? Das hab ich jetzt nicht mehr ausprobiert.

Jedenfalls konnte ich tatsächlich eine neue Mysql in der Version 5.0 anlegen. Die war nach wenigen Minuten einsatzbereit. Die Zugangsdaten hatten sich zwar geändert, aber die kann man in MySQLDumper online direkt wieder anpassen. Die Verbindung war da, das Backup mit meiner angepassten Datei lief jetzt reibungslos und erfolgreich!

Abschließend wird die settings.php von Drupal mit dem neuen Datenbank-Zugang angepasst und wieder auf den Server geladen. Das war es dann schon. Drupal mit Mysql 5.0 läuft sofort, alle Daten und Funktionen sind noch da.

Fazit eines Mysql-Laien

Puh