Migration Datenbank MySQL 3.23 auf 5.6

Das mir eine MySQL Kundendatenbank mal den letzten Nerv rauben würde, konnte ich mir beim besten Willen nicht vorstellen. Ich habe die letzten 2 Wochen ganz schön Nerven lassen müssen, um diese komplett veraltete, aber immer noch produktiv verwendete Datenbank zu sichern und in eine Form zu bringen, mit der die alten Daten in das neue System überführt werden können. Hier mein kleiner Erfahrungsbericht mit allen Hürden die zu nehmen waren.

Wie in solchen Fällen üblich, fange so eine Aufgabe mit einmal googeln an. Ich bin auch nur ein Mensch und alles kann ich auch nicht wissen. Ich habe zwar viel mit MySQL-Datenbanken und deren Verwendung zu tun. Sei es bei der Installation eines neuen Webshops oder einer anderen Internetseite. Oft werden die dafür notwendigen administrativen Aufgaben von Tools und Assistenten abgenommen. Hier konnte ich aber nicht auf solche Tools oder Assistenten zurückgreifen. Auf dem Server war MySQL Server 3.23 installiert und dass völlig ohne irgendwelchen Schnickschnack. Welche Schritte ich gehen muss sind klar:

1. Datenbank sichern

2. Datenbank migrieren

3. SQL-Abfragen für den Import schreiben

Herausforderung Datenbanksicherung

Der Produktiver Server ist ein alter Intel-Server mit XEON Prozessor, einem Gigabyte RAM und definitiv viel zu wenig Platz auf der C-Partition. Die ersten drei versuche mit

mysqldump --opt datenbank > datenbank.sql

einen Dump der Datenbank auf der Kiste zu erstellen sind gnadenlos fehlgeschlagen. Die Produktive Datenbank hat mittlerweile eine Größe von 4 GB und selbst mit dem Parameter Quick ist mir die Kiste in einen Speicher-Overflow gelaufen. Da war nichts zu machen.

Ich habe mich dann zu einer sehr radikalen Maßnahme entschieden. Es war nicht so einfach noch einen Download für den MySQL Server 3.28 zu finden, aber nach ein paar Anläufen hatte ich es geschafft. Den Download gibt es hier:

http://olex.openlogic.com/packages/mysql/3.23.58

Die Datenbank habe ich einfach per Drag and Drop auf einen USB-Stick kopiert und anschließend ins Datenverzeichnis der neuen Installation auf der virtuellen Maschine kopiert. Dieser hatte ich im Vorfeld 4 virtuelle Kerne gegeben und mit 16 GB RAM versorgt. Dass sollte jetzt reichen.

Auf zum nächsten Versuch – Eingabeaufforderung starten, ins bin-Verzeichnis der MySQL Server Installation wechseln und folgenden Befehl eingegeben:

$ mysqldump --add-drop-table --add-locks –all --quick --lock-tables datenbank > datenbank.sql

Okay jetzt hatte ich nach mal gerade 15 Minuten meine Dump der Datenbank in der Größte von 5 Gigabyte. Erstmal auf meinem Server absichern.

Während meiner ganzen Suche nach der richtigen Lösung und da war ich mehr als eine Woche auf der Suche hatte ich folgende zwei Seiten gefunden:

http://hisdeedsaredust.com/2009/02/mysql-version-3-to-version-5/

http://craiccomputing.blogspot.de/2009/06/migrating-mysql-323-database-to-50.html

Das ist die Basis für das was nun folgt. Ich war mir zwar nicht sicher, ob ich auf dem richtigen Weg war, aber auf einen Versuch wollte ich es anlegen. Beim Lesen der Artikel musste ich aber schnell feststellen, mit meinen Windows Gurken komme ich da nicht weiter. Also ein aktuelles Ubuntu downloaden, ebenfalls in auf eine virtuellen Maschine installieren und dann noch den MySQL-Server 5.6 aus dem Softwarecenter nachinstallieren.

Alles was jetzt kommt muss im Terminal unter Linux gemacht werden. Ich habe mir den Dump der Datenbank vom Server auf den neuen Ubuntu Client gesichert und jetzt muss ich diesen Dump für den neuen Server aufbereiten. Im ersten Schritt ändere ich die Zeichencodierung von Latin1 nach UTF8 dazu gebe ich im Terminal folgenden Befehl ein:

$ iconv -f latin1 -t utf8 < datenbank.sql > datenbank_utf8.sql

Okay jetzt hat meine Datenbank schon mal die richtige Zeichencodierung. Mal kurz getestet ob ich diese Datenbank schon importieren kann. Den Versuch hätte ich mir aber, wenn ich richtig gelesen hätte sparen können. Zuerst muss ich noch den Kommentar im Header des SQL-Dumps löschen. Dazu gebe ich im Terminal-Fenster folgenden Befehl ein:

nano datenbank_utf8.sql

ein.

Jetzt kann ich die ersten fünf Zeilen in dem Dump der Datenbank löschen, damit beim Import der neue SQL-Server nicht mehr meckert, meine Datenbank hätte die falsche Version.

-- MySQL dump 8.22

--

-- Host: localhost Database: mydatabase

---------------------------------------------------------

-- Server version 3.23.54

Jetzt muss ich noch den Typ der Tabellen anpassen. Der Befehl TYPE wird vom aktuellen SQL-Server nicht mehr unterstützt und die Tabellen müssen von MyISAM in INNODB umgewandelt werden. Den Weg dorthin habe ich hier gefunden:

http://support.severalnines.com/entries/24434706-Migrate-MyISAM-tables-to-INNODB-using-mysqldump

Okay hier muss ich den die Datenbank zweimal anfassen. Mit dem Befehl

sed -i.bak 's#MyISAM#innodb#g' datenbank_utf8.sql

werden die Tabellen migriert.

Mit dem gleichen Befehl nur mit anderen Werten zwischen den #-Zeichen ändere ich den Parameter TYPE in Engine

sed -i.bak 's#TYPE#ENGINE#g' datenbank_utf8.sql

Jetzt brauch ich noch eine zusätzliche Datei datenbank_header mit ein paar SQL-Anweisungen um die Migration der Datenbank durchzuführen. Dazu nehme ich wieder den Text-Editor Nano unter Ubuntu und gebe im Terminal-Fenster folgenden Befehl ein:

nano datenbank_header

In die leere Textdatei gebe ich folgende Befehlszeilen ein:

set names utf8;

drop database if exists daten;

create database daten character set utf8;

use daten;

Die Änderungen mit STRG+O speichern und den Editor mit STRG+X beenden. Jetzt kann der bearbeitete SQL-Dump importiert werden. Dafür gebe ich im Terminal-Fenster folgenden Befehl ein:

cat datenbank_header datenbank_utf8.sql | mysql -u root -p

Nach rund 2 Wochen Recherchearbeit und unzähligen Stunden am Computer läuft der Import langsam aber sicher durch. Bis jetzt hat der Import rund 16 Stunden für eine 4 Gigabyte große Datenbank benötigt und ist immer noch nicht fertig. Aber ich kann behaupten, dass mein Plan aufgegangen ist und ich morgen damit beginnen kann, die Tabellen für den Import in JTL-Wawi anzupassen. Spannend wird, auf welchen Weg ich die Aufträge aus der alten Datenbank in die passenden XML-Dateien exportieren kann, damit ich Sie anschließend über den XML-Auftragsimport in die Wawi importieren kann. Es gibt also noch eine Menge zu tun und damit auch viel Stoff.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.