Datenbank-Migration im ISPConfig

Es gibt Situationen, in denen es notwendig wird, eine Datenbank auf eine andere Version zu migrieren. Dieser Vorgang ist oft recht aufwändig und erfordert an verschiedenen Stellen eine gewisse Routine. Die Erfahrung und Routine, die wir bei Timme Hosting gesammelt haben, haben wir in eine Funktion innerhalb von ISPConfig integriert, um unseren Kunden noch mehr nützliche Features anzubieten. Dieser Beitrag beschreibt, wie Sie Datenbanken per Klick zwischen mehreren Versionen migrieren können und welche Details dabei beachtet werden sollten.

Bevor Sie mit der Migration beginnen, sollten Sie einige wichtige Aspekte berücksichtigen:

• Wartungsmodus aktivieren: Wenn die Migration direkt final durchgeführt werden soll, ist es wichtig, den Wartungsmodus Ihres Content Management Systems (CMS) zu aktivieren. Alternativ kann auch der Wartungsmodus über ISPConfig aktiviert werden (siehe Abschnitt Wartungsmodus).
• MyISAM-Tabellen beachten: MyISAM-Tabellen können während der Migration zu Tabellen-Locks führen und große Aussetzer der Webseite verursachen. Es ist daher ratsam, diese Tabellen vor der Migration in InnoDB-Tabellen umzuwandeln, besonders wenn die Webseite während der Migration erreichbar bleiben muss. Eine Anleitung dazu finden Sie in unserem Leitfaden MyISAM-Tabellen in InnoDB umwandeln.
• Zeitbeschränkung beachten: Datenbankmigrationen, die länger als 4 Stunden dauern, werden automatisch fehlschlagen. Migrationen, die so umfangreich sind, sollten nicht unbeaufsichtigt durchgeführt werden. Das Timeout wurde gesetzt, um unerwartete Probleme zu vermeiden.
• Spezielle Datenbankobjekte: Objekte wie Views, Events, Trigger, Stored Procedures und Stored Functions werden während der Migration nicht übernommen. Etwaige DEFINER werden aus den Datenbank-Dumps entfernt, um die Migration möglichst störungsfrei und erfolgreich durchlaufen zu lassen.

Um während der Migration Dateninkonsistenzen oder Fehler zu vermeiden, sollte verhindert werden, dass währenddessen neue Daten in die Datenbank geschrieben werden. Gehen Sie wie folgt vor:

1. Wartungsmodus im CMS aktivieren: Die meisten CMS bieten die Möglichkeit, einen Wartungsmodus zu aktivieren. Dieser verhindert, dass Benutzer während der Migration Änderungen vornehmen können.
2. Wartungsmodus über ISPConfig: Falls Ihr CMS keinen Wartungsmodus anbietet, können Sie den Wartungsmodus auch über ISPConfig aktivieren. Eine Anleitung dazu finden Sie in unserem Leitfaden Wartungsmodus in ISPConfig aktivieren.
3. Cronjobs und Supervisor-Dienste prüfen: Überprüfen Sie, ob für die Webseite Cronjobs oder Supervisor-Dienste eingerichtet sind. Deaktivieren Sie diese vor beginn der Migration und beenden Sie bereits laufende Prozesse.

Bevor Sie die Migration auf Ihrer Live-Datenbank durchführen, ist es empfehlenswert, den Prozess zunächst mit einer Staging-Datenbank zu testen. Dies ermöglicht es Ihnen, ein Gefühl für die Dauer der Migration zu bekommen und mögliche Probleme im Voraus zu erkennen.

Die eigentliche Migration kann über ISPConfig durchgeführt werden und steht Kunden mit einem Managed vServer, Managed Server oder Managed ScaleServer zur Verfügung.

Managed vServer, Managed Server & ScaleServer: Loggen Sie sich bitte über Ihr Server Control Panel ein.

Sie können den Status der Migration jederzeit überprüfen:

1. Status abrufen: Klicken Sie erneut auf das "→"-Symbol neben der Datenbank.


2. Statusanzeigen:

• Status pending: Die Migration ist noch nicht gestartet und wird in Kürze beginnen. Innerhalb der nächsten 5 Minuten sollte sich der Status ändern.
• Status processing: Der Migrationsprozess ist gestartet und die Inhalte der Datenbank werden in die neue Datenbank kopiert.
• Status error: Es ist ein unerwarteter Fehler aufgetreten und die Migration wurde abgebrochen. Details zum Fehler finden Sie in der Info-Spalte.
• Status ok: Die Migration wurde erfolgreich abgeschlossen. Der neue Port wird in der Info-Spalte angezeigt.

Nachdem der Status auf "ok" gewechselt hat, ist der Migrationsprozess auf dem Server abgeschlossen. Nun müssen Sie einige abschließende Schritte durchführen:

1. Anpassung der CMS-Konfiguration:
• Datenbank-Port und -Host anpassen: Passen Sie in der Konfigurationsdatei Ihres CMS den Datenbank-Port und gegebenenfalls den Datenbank-Host an. Bei Zieldatenbanken, die nicht die Systemdatenbank sind, sollte der Host auf 127.0.0.1 eingestellt werden.
• Caches leeren: Leeren Sie etwaige Caches, da einige CMS die Datenbankeinstellungen im Cache speichern.
2. Funktionstest:
• Umfangreich testen: Überprüfen Sie, ob das CMS mit der neuen Datenbank einwandfrei funktioniert. Testen Sie dabei alle wichtigen Funktionen Ihrer Anwendung.
3. Migration abschließen oder rückgängig machen:
• Migration abschließen: Wenn alles funktioniert, können Sie die Migration final abschließen, indem Sie auf "Migration abschließen" klicken. Dadurch wird die alte Datenbank vom Server gelöscht.
• Migration rückgängig machen: Sollte es Probleme geben, können Sie die Migration rückgängig machen, indem Sie auf "Migration rückgängig machen" klicken. Dabei wird die Zieldatenbank gelöscht und das CMS verwendet wieder die ursprüngliche Datenbank. Nach dem Testen müssen Sie wieder den ursprünglichen Port hinterlegen.

Die Dauer der Migration hängt von der Größe der Quelldatenbank ab und kann von wenigen Minuten bis zu mehreren Stunden variieren. Beachten Sie:

• Kein Fortschrittsbalken: Ein detaillierter Fortschrittsstatus kann nicht angezeigt werden, da der Fortschritt nicht immer eindeutig ermittelt werden kann.
• Überwachung der Prozesse: Wenn Sie mit der Shell vertraut sind und sich mit einem Benutzer ohne Jailkit auf dem Server angemeldet haben, können Sie mit dem Befehl ps den Migrationsprozess in der Prozessliste finden und so feststellen, ob er noch aktiv ist.

Erfahrungswerte zur Migrationsdauer

Um Ihnen eine Vorstellung von den zu erwarteten Zeiten zu geben, haben wir einige Tests mit unterschiedlich großen Datenbanken durchgeführt:

Beispiel 1: Leere WordPress-Installation

• Größe der Datenbank auf dem Dateisystem: 1,4 MB
• Dauer der Migration: 0,924 Sekunden

Beispiel 2: Leere Shopware 5 Installation

• Größe der Datenbank auf dem Dateisystem: 39 MB
• Dauer der Migration: 15,826 Sekunden

Beispiel 3: Leere Shopware 6 Installation

• Größe der Datenbank auf dem Dateisystem: 35 MB
• Dauer der Migration: 16,389 Sekunden

Beispiel 4: Große Datenbanken von Wikimedia Dumps

Wir haben verschiedene SQL-Dumps von dumps.wikimedia.org verwendet.

a) wikidatawiki-20240820-geo_tags.sql (10.090.155 Datensätze)

• Größe der Datenbank auf dem Dateisystem: 637 MB
• Migrationsdauer:
  • MariaDB 10.11 (Systemdatenbank) zu MySQL 8.4: 17 Minuten 54 Sekunden
  • MariaDB 10.11 (Systemdatenbank) zu MariaDB 11.4: 10 Minuten 56 Sekunden
  • MySQL 8.4 zu MariaDB 10.11 (Systemdatenbank): 4 Minuten 58 Sekunden
  • MySQL 8.4 zu MariaDB 10.6: 10 Minuten 42 Sekunden
  • MariaDB 10.6 zu MySQL 8.4: 18 Minuten 26 Sekunden

b) wikidatawiki-20240820-wbs_propertypairs.sql (3.793.176 Datensätze)

• Größe der Datenbank auf dem Dateisystem: 201 MB
• Migrationsdauer:
  • MariaDB 10.11 (Systemdatenbank) zu MySQL 8.4: 1 Minute 34 Sekunden
  • MariaDB 10.11 (Systemdatenbank) zu MariaDB 11.4: 1 Minute 9 Sekunden
  • MySQL 8.4 zu MariaDB 10.11 (Systemdatenbank): 53 Sekunden
  • MySQL 8.4 zu MariaDB 10.6: 1 Minute 7 Sekunden
  • MariaDB 10.6 zu MySQL 8.4: 1 Minute 35 Sekunden

c) wikidatawiki-20240820-wbc_entity_usage.sql (11.678.429 Datensätze)

• Größe der Datenbank auf dem Dateisystem: 957 MB
• Migrationsdauer:
  • MariaDB 10.11 (Systemdatenbank) zu MySQL 8.4: 2 Stunden 7 Minuten 56 Sekunden
  • MariaDB 10.11 (Systemdatenbank) zu MariaDB 11.4: 43 Minuten 19 Sekunden
  • MySQL 8.4 zu MariaDB 10.11 (Systemdatenbank): 8 Minuten 5 Sekunden
  • MySQL 8.4 zu MariaDB 10.6: 41 Minuten 23 Sekunden

Hinweis: Da MySQL und MariaDB nicht mehr vollständig kompatibel sind, müssen beispielsweise Statistikdaten bei der Migration in eine MySQL-Datenbank neu berechnet werden, was die Migration verzögern kann.

• Backup erstellen: Bevor Sie mit der Migration beginnen, empfehlen wir Ihnen, ein Sofort-Backup über ISPConfig zu erstellen, sich den Downloadlink schicken zu lassen und das Backup herunterzuladen. Dies ermöglicht es Ihnen, im Falle von Problemen den ursprünglichen Zustand wiederherzustellen. Eine Anleitung dazu finden Sie in unserem Leitfaden Backups verwalten mit ISPConfig.
  Hinweis: Wenn Sie die Migration abschließen, werden die alte Datenbank und deren Backups entfernt. Sie können diese dann im Falle von Problemen nicht ohne separates Backup wiederherstellen.
• Kompatibilitätsprüfung: Überprüfen Sie, ob Ihre Anwendung mit der Zielversion der Datenbank kompatibel ist. Manche CMS oder Anwendungen können Probleme mit bestimmten Datenbankversionen haben.
• MyISAM zu InnoDB: Wenn Ihre Datenbank noch MyISAM-Tabellen enthält, sollten Sie diese vor der Migration in InnoDB-Tabellen umwandeln, um Probleme mit Tabellen-Locks zu vermeiden. Weitere Informationen finden Sie in unserem Leitfaden MyISAM-Tabellen in InnoDB umwandeln.
• Spezielle Datenbankobjekte: Beachten Sie, dass spezielle Datenbankobjekte wie Views, Events, Trigger, Stored Procedures und Stored Functions nicht automatisch migriert werden. Diese müssen gegebenenfalls manuell übertragen werden.
• Timeout vermeiden: Da die Migration nach 4 Stunden automatisch abbricht, sollten Sie sicherstellen, dass Ihre Datenbank kleiner ist oder den Prozess entsprechend überwachen.
• Support kontaktieren: Wenn Sie unsicher sind oder Unterstützung benötigen, zögern Sie nicht, unseren Support zu kontaktieren.

Die Migration einer Datenbank von einer Version in eine andere kann komplex sein, aber mit den richtigen Werkzeugen und Vorbereitungen lässt sich der Prozess erheblich vereinfachen. Durch die Integration unserer Migrationsroutine in ISPConfig bieten wir Ihnen die Möglichkeit, Datenbanken mit nur wenigen Klicks zu migrieren. Achten Sie dabei stets auf die hier beschriebenen Details und Hinweise, um einen reibungslosen Ablauf zu gewährleisten.

Weiterführende Ressourcen:

• MyISAM-Tabellen in InnoDB umwandeln
• ISPConfig-Leitfaden
• Timme Hosting Support

Geschafft! Sie haben eine Datenbank von einer Version zu einer anderen migriert.

Noch mehr Anleitungen ▶