Migration von MySQL zu Cloud SQL

In diesem Dokument wird beschrieben, wie Sie die Migration einer nicht partitionierten MySQL 5.7-Datenbank zu Cloud SQL planen – einem vollständig verwalteten Datenbankdienst in Google Cloud. Es wird davon ausgegangen, dass Sie eine MySQL-Datenbank haben und im Allgemeinen mit den Konzepten von MySQL und Google Cloud vertraut sind.

Die in diesem Dokument beschriebenen Konzepte gelten für andere Versionen von MySQL und für MariaDB, eine beliebte Open-Source-Fork von MySQL. Bei anderen Versionen als MySQL 5.7 müssen die Prozesse jedoch möglicherweise geringfügig geändert werden. Es gibt viele Tools von Drittanbietern und Cloud SQL-Partner, mit deren Hilfe Sie eine Datenbankmigration planen können. In diesem Dokument werden nur native MySQL- und Google Cloud-Funktionen und keine zusätzlichen Tools oder Partner behandelt.

Eine begleitende Anleitung führt Sie durch einen der in diesem Dokument beschriebenen Migrationsprozesse.

Übersicht

Bei der Migration einer MySQL-Datenbank in eine andere Umgebung müssen Sie zwei Elemente verschieben:

  • Die Daten in der Datenbank. Dies ist die Speicherebene der Datenbank.
  • Das Verwaltungssystem, das konsistente Lese- und Schreibvorgänge auf Speicherebene verarbeitet. Dies ist die Verwaltungsebene.

Diese Elemente müssen ständig synchronisiert werden, damit die Datenbank funktioniert. Auch eine kleine Datenbank kann Tausende von Anfragen pro Sekunde erhalten. Verzögerungen bei Transaktionen oder Netzwerkprobleme zwischen den Speicher- und Verwaltungsebenen haben negative Auswirkungen auf die Datenbank, die abhängigen Anwendungen und die Nutzerzufriedenheit.

Migrationsmethoden

MySQL bietet zwei Funktionen, die Sie bei der Migration zu Cloud SQL unterstützen können. Diese Funktionen bilden die Grundlage für zwei Strategien zur Migration von MySQL-Datenbanken: Export/Import-Migration und Migration mit Hochstufung externer Replikate.

Export/Import-Migration

Bei der Export/Import-Strategie exportieren Sie mit dem MySQL-Befehl mysqldump alle Daten auf der Speicherebene der Quelldatenbank. Anschließend importieren Sie diese Daten direkt auf eine neue Datenbankverwaltungsebene. Hierfür müssen Sie normalerweise während des gesamten Migrationsprozesses Ausfallzeiten der Datenbank in Kauf nehmen, da währenddessen alle Daten abgestimmt sein müssen.

Migration mit Hochstufung externer Replikate

Bei der Migrationsstrategie zur Hochstufung externer Replikate erstellen Sie ein externes Datenbankreplikat und synchronisieren die vorhandenen Daten mit diesem Replikat. Dies ist mit minimalen Ausfallzeiten für die vorhandene Datenbank möglich.

Wenn Sie eine replizierte Datenbank haben, verfügen die beiden Datenbanken über unterschiedliche Rollen, die in diesem Dokument als primär und Replikat bezeichnet werden.

Nach der Synchronisierung der Daten stufen Sie das Replikat zur primären Datenbank hoch, um die Verwaltungsebene mit minimalen Auswirkungen auf die Datenbankverfügbarkeit zu verschieben.

In Cloud SQL können Sie die Hochstufung externer Replikate ganz einfach mithilfe des automatisierten Migrationsworkflows durchführen. Dieser Prozess automatisiert viele der für diesen Migrationstyp erforderlichen Schritte.

MySQL-Datenbank für die Migration vorbereiten

Bevor Sie die Migrationsschritte ausführen, müssen Sie dafür sorgen, dass Ihre Datenbank für beide Optionen vorbereitet ist. MySQL wird mit einigen Standardkonfigurationen installiert und kann entsprechend den Anforderungen der Anwendung angepasst werden. Prüfen Sie vor der Migration, ob MySQL wie in diesem Abschnitt beschrieben konfiguriert ist. So verringern Sie das Risiko von Migrationsfehlern und begrenzen mögliche Ausfallzeiten.

Logische Sicherung durchführen

Bei beiden Migrationsmethoden nehmen Sie Änderungen an Ihrer MySQL-Datenbank vor. Bevor Sie Migrationsschritte ausführen, sollten Sie zum Schutz der Daten in Ihrer Datenbank mit dem MySQL-Befehl mysqldump einen Datenexport erstellen, den Sie als Sicherung speichern. Diese Sicherung dient als Ausgangspunkt für beide Migrationsmethoden.

Mit dem Befehl mysqldump erstellen Sie einen Snapshot aller Daten in der Datenbank. Je nach Größe Ihrer Datenbank kann dieser Vorgang weniger als eine Sekunde oder auch mehrere Stunden dauern. Wenn Daten nach dem Erstellen des Snapshots geändert werden, werden diese Änderungen nicht im endgültigen Snapshot erfasst. Wenn Sie den Migrationsprozess mit Hochstufung externer Replikate verwenden, ist dies kein Problem. Bei dem Export/Import-Migrationsprozess kann dies jedoch zu Dateninkonsistenzen und Datenverlusten führen.

Bewahren Sie die vollständige Sicherung sicher auf. Zu den Optionen gehören Cloud Storage, ein lokales Objektspeichersystem oder ausgelagerte Sicherungen.

Benchmark-Leistungsmesswerte für Datenbanken

Wenn Sie mit der Migration beginnen, sollten Ihnen die Leistungsbenchmarks Ihrer aktuellen Anwendung und Datenbank vollständig vorliegen. So können Sie das erwartete Verhalten und die aktuellen Leistungsmesswerte nachvollziehen.

Sorgen Sie dafür, dass Ihre Benchmarks die Anwendungsfälle für Ihre Anwendungen und Ihre Datenbank darstellen. Wenn Sie später die Leistung der migrierten Datenbank anhand der Benchmarks vergleichen, können Sie dadurch aussagekräftige Vergleiche zwischen der alten und neuen Datenbankbereitstellung durchführen.

Verbindungsoptionen festlegen

Die Anforderungen an die Netzwerkverbindung sind für jede Migrationsstrategie unterschiedlich. Die wichtigste Frage bei der Festlegung der Methode ist, ob über eine öffentliche IPv4-Adresse auf Ihre Datenbank zugegriffen werden kann.

Wenn Sie mit dem automatisierten Migrationsworkflow von Cloud SQL eine Migration mit Hochstufung externer Replikate durchführen, muss Ihre vorhandene Datenbank über eine IPv4-Adresse öffentlich zugänglich sein. Die Zieldatenbank in Cloud SQL erfordert während des Hochstufungs- oder Migrationsprozesses eine dauerhafte Netzwerkverbindung. Abhängig von der Größe Ihrer Datenbank können diese Prozesse längere Zeit in Anspruch nehmen.

Sie sollten auch Verbindungsoptionen für Ihre Zieldatenbank berücksichtigen. Cloud SQL kann private IP-Adressen verwenden. Sie können Cloud SQL auch für die Verwendung von öffentlichen IP-Verbindungen konfigurieren.

Root-Passwort festlegen

Während der Migration führen Sie viele privilegierte MySQL-Befehle und -Aufgaben aus. Daher benötigen Sie Zugriff auf den MySQL-Nutzer root oder auf ein Konto mit den Berechtigungen SUPER und GRANT. Wenn Sie den Nutzernamen und das Passwort für eines dieser privilegierten Konten nicht kennen, wenden Sie sich an Ihre Datenbankadministratoren oder führen Sie die MySQL-Schritte zum Zurücksetzen von Passwörtern aus.

Testmigration durchführen und ein Runbook erstellen

Vor einer Produktionsmigration sollten Sie Testmigrationen durchführen. Dadurch können Sie Ihre Schritte überprüfen, sich mit Ihren Methoden vertraut machen und die für die Migration erforderliche Dauer vorhersagen. Anhand der gewonnenen Erkenntnisse können Sie ein Runbook erstellen, das Ihnen bei der Migration hilft. Nutzen Sie das Runbook als Arbeitsdokument, um Sie bei der Koordination, Fehlerbehebung und Ausführung Ihrer Migration zu unterstützen.

Dieses Dokument kann als Einführung in die Erstellung Ihres Runbooks für die Datenbankmigration dienen.

Anwendung für eine Datenbankmigration vorbereiten

Der letzte vorbereitende Schritt besteht darin, Ihre Anwendung für die Migration vorzubereiten. Eine Beschreibung aller Verbindungsmethoden zwischen Anwendung und Datenbank ist in diesem Dokument nicht möglich. Sie sollten jedoch verstehen, wie sich die Verbindung zwischen IP-Adressen und dem Domain Name System (DNS) auf Ihre Anwendung auswirkt.

Der Zugriff auf eine Datenbank findet oft über das öffentliche oder interne DNS statt. Bei Verwendung des DNS kann die zugrunde liegende IP-Adresse der Zieldatenbank geändert werden, ohne den Anwendungscode zu aktualisieren. Wenn Ihre Anwendung DNS-Einträge für die Datenbankverbindung verwendet, sollten Sie die DNS-Werte für die Gültigkeitsdauer (Time-to-Live, TTL) dieser DNS-Einträge für die Migration normalerweise senken.

DNS-TTL-Werte werden in Sekunden gemessen und stellen die Gültigkeit eines auf einem Client oder Host gespeicherten DNS-Eintrags dar. Diese Zeit wird auch als DNS-Cache-Fenster bezeichnet. DNS-TTL-Standardwerte sind für jeden DNS-Anbieter unterschiedlich. In Cloud DNS wird die TTL beispielsweise standardmäßig auf 5 Minuten (300 Sekunden) festgelegt. Da sich die DNS-Einträge der Datenbank nur selten ändern, hat Ihr DNS-Administrator dies möglicherweise viel höher eingestellt.

Wenn die DNS-TTL-Werte bei der Migration Ihrer Datenbank hoch sind, kann dies die Ausfallzeit der Datenbank verlängern, wenn Clients einen im Cache gespeicherten DNS-Wert haben. Durch Senken des TTL-Werts erzwingen Sie, dass Clients häufiger nach aktualisierten Einträgen suchen. Dadurch wird die Ausfallzeit der Datenbank minimiert.

Wenn Sie Änderungen an den DNS-Einträgen für die Datenbank vornehmen möchten, sollten Sie diese Zahl auf den kleinstmöglichen konfigurierbaren Wert setzen. Wenn Sie einen SaaS-basierten DNS-Anbieter nutzen, kann es zu höheren Kosten kommen. Wenden Sie sich an Ihren Anbieter oder Administrator, bevor Sie diese Änderung vornehmen.

Export/Import-Migration

Die Export/Import-Migrationsstrategie verwendet den MySQL-Befehl mysqldump, um einen logischen Snapshot aus der Datenbank der Quellumgebung zu exportieren. Anschließend importieren Sie den Snapshot in die Datenbank der Zielumgebung.

Diese Methode ist zwar sehr einfach, hat aber den Nachteil, dass während der Migration Ausfallzeiten für die Datenbank auftreten. Da Transaktionen in großen Datenbanken kontinuierlich stattfinden, gehen Administratoren normalerweise folgendermaßen vor:

  1. Quelldatenbankfunktion zum Schreiben neuer Daten deaktivieren
  2. Snapshot von der Quelldatenbank erstellen
  3. Snapshot in die Zieldatenbank importieren
  4. Anwendungskonfiguration so aktualisieren, dass sie auf die neue Datenbank verweist
  5. Leistung der neuen Datenbank überprüfen

Das folgende Diagramm veranschaulicht diese Sequenz:

Abfolge der Migration von einer lokalen MySQL-Datenbank zu einem Dateiexport in Cloud Storage und anschließend zu MySQL, das auf Cloud SQL ausgeführt wird

Durch diese Sequenz wird sichergestellt, dass zwischen dem Zeitpunkt, an dem Sie Schreibvorgänge in der Quelldatenbank stoppen, und dem Zeitpunkt, an dem Sie Schreibvorgänge in der neuen Datenbank starten, keine Änderungen an den Daten vorgenommen werden. Je nach Größe Ihrer Daten kann dieser Prozess zu längeren Ausfallzeiten Ihrer Anwendung führen. Dies ist für viele Unternehmen und Anwendungen oft nicht akzeptabel.

Wenn Sie die Export/Import-Migrationsstrategie verwenden, benötigt Ihre Datenbank keine externe Verbindung zu Cloud SQL. Sie müssen jedoch die mysqldump-Dateien an einen Speicherort exportieren können, auf den Cloud SQL zugreifen kann. Je nach Größe der mysqldump-Datei kann dieser Datenimport/-export sehr lange dauern. Außerdem können komplexe Kopier- und Überprüfungstechniken für die Dateien erforderlich sein, um zu gewährleisten, dass alle Datenzeilen und Transaktionsinformationen korrekt kopiert werden.

Außerdem haben die Datenklassifizierungsregeln Ihrer Organisation möglicherweise Einfluss darauf, ob Sie die mysqldump-Dateien an anderen Speicherorten speichern können. Lesen Sie diese Regeln, bevor Sie eine Methode zum Speichern von Daten auswählen.

Schrittweise Anleitung für die Export/Import-Migration

Die folgenden Abschnitte enthalten Details zu den einzelnen Schritten der gesamten Sequenz.

Schreibvorgänge deaktivieren

Der Administrator konfiguriert die Datenbank so, dass Schreibvorgänge verhindert werden. Dies wird auch als Sperren oder Einfrieren der Datenbank bezeichnet. Danach schlägt jede Schreibtransaktion fehl, die an die Datenbank gesendet wird. Lesetransaktionen für die Datenbank oder Replikate funktionieren jedoch weiterhin wie gewohnt. Sie sollten einige Testabfragen ausführen, um dieses Verhalten zu überprüfen, bevor Sie mit den nachfolgenden Schritten fortfahren.

Prüfen Sie, welche Anwendungen vom Sperren der Datenbank betroffen sein könnten. Möglicherweise müssen Sie Nutzer, Kunden, Administratoren und andere von der Datenbank abhängige Abteilungen benachrichtigen, um einen größeren Systemausfall zu verhindern.

Daten exportieren

Nachdem die Datenbank gesperrt wurde, führen Sie den Befehl mysqldump in der alten Datenbank aus, um einen vollständigen Export der Daten zu erstellen. Nach Abschluss des Exportprozesses muss diese Datei an einen Speicherort verschoben werden, auf den die neue Datenbank zugreifen kann.

Achten Sie darauf, dass Sie Sicherungsdateien an ein anderes physisches Laufwerk als das Laufwerk mit der Produktionsdatenbank senden. Diese Trennung verringert E/A-Konflikte im Laufwerk und kann die Geschwindigkeit des Sicherungsprozesses erhöhen. Dadurch, dass Sie die Schreiblast wegnehmen und das Hauptlaufwerk somit entlasten, reduzieren Sie die Auswirkungen auf die Vorgänge in Ihrer Produktionsdatenbank. Dank dieser Trennung verringert sich auch die Wahrscheinlichkeit, dass nicht genügend Speicherplatz auf dem Laufwerk vorhanden ist, das Ihre Produktionsdatenbank enthält.

Durch Komprimieren der Ausgabe des Befehls mysqldump kann außerdem die Gesamtzahl der für die Sicherung erforderlichen Schreibvorgänge reduziert werden. Für die Komprimierung sind möglicherweise mehr CPU-Ressourcen erforderlich. Prüfen Sie daher, wie sich dies auf die Leistung der Datenbankverwaltungsebene auswirkt.

Weitere Informationen finden Sie unter Daten für den Import in Cloud SQL exportieren.

Daten importieren

Die Dumpdatei muss aus der alten Datenbank in die neue Datenbank importiert werden. Beim Import werden die Datenbanktabellen und alle Zeilen aus der alten Datenbank neu erstellt. Die für einen Import benötigte Zeit ist mit der Zeit für den Export vergleichbar, wenn ähnliche Systemressourcen vorhanden sind. Wenn Sie Systemressourcen im Rahmen der Migration upgraden, kann der Importprozess schneller sein als der Export.

Weitere Informationen finden Sie unter Daten in Cloud SQL importieren.

Nach dem Import der Daten sollten Sie die Benchmark-Leistungsinformationen prüfen, die Sie beim Testen der Quelldatenbank erhalten haben. Sie können dann auf Lesevorgängen basierende Produktionsabfragen für die neue Datenbank ausführen, um zu gewährleisten, dass die neue Datenbank die Leistungsanforderungen Ihrer Anwendungen erfüllt.

Anwendungen aktualisieren

Sobald Sie die neue Datenbank verwenden möchten, müssen Sie Ihre Anwendungen aktualisieren, damit sie die neue Datenbank unterstützen. Dafür gibt es mehrere Methoden:

  • Wenn der Datenbankendpunkt oder die IP-Adresse Ihrer Anwendung direkt im Quellcode definiert ist, aktualisieren Sie den Code und stellen dieses Update für alle Anwendungen bereit, die Zugriff auf die Datenbank benötigen.
  • Wenn Ihre Anwendung zum Zugriff auf die Datenbank auf einen DNS-Eintrag verweist, aktualisieren Sie den DNS-Eintrag über Ihren DNS-Anbieter, damit er die neue Adresse für den Datenbankendpunkt widerspiegelt.
  • Wenn Ihre Anwendung zum Zugriff auf die Datenbank auf einen Load-Balancer verweist, registrieren Sie den neuen Datenbankendpunkt beim Load-Balancer.

Wenn Sie Ihre Anwendungen auf Cloud SQL umstellen, sollten Sie den Pufferpool aufwärmen. Dadurch wird die Abfragelatenz Ihrer Anwendungen minimiert, bevor die Datenbank Daten im Arbeitsspeicher speichert. Sie können das MySQL-Log für langsame Abfragen aus Ihrer Quellproduktionsdatenbank verwenden, um ein Skript zum Ausführen aller SELECT-Anweisungen zu erstellen, die den Cache in Ihrer neuen Instanz füllen. Dies sollten Sie tun, bevor Sie Schreibvorgänge aktivieren.

Es gibt viele Tools von Drittanbietern und Partner, die Sie beim Aufwärmen des Pufferpools unterstützen können.

Schreibvorgänge aktivieren

Nachdem Sie geprüft haben, ob der aktualisierte Anwendungscode mit der neuen Datenbank kommunizieren kann, müssen Sie die Schreibschutzsperre für die neue Datenbank entfernen. Nach diesem Schritt können Sie über Ihre Anwendung prüfen, ob die Datenbank korrekt funktioniert. Sie sollten auch weitere Benchmarktests durchführen, um zu prüfen, ob Ihre Datenbankleistung weiterhin den Anforderungen Ihrer Anwendung entspricht.

Wenn Sie bei der Prüfung festgestellt haben, dass alle Daten in beiden Datenbanken konsistent sind, können Sie einige Bereinigungsaufgaben ausführen:

  • Nutzer benachrichtigen, dass die Ausfallzeit vorbei ist
  • Statusseiten aktualisieren und alle Statusmeldungen aus der Anwendung entfernen
  • Alle geänderten DNS-TTL-Werte auf ihre ursprünglichen Werte zurücksetzen

Vorschläge zur Optimierung der Importzeit für Export/Import-Migrationen

Es gibt verschiedene Möglichkeiten, die Importgeschwindigkeit einer mysqldump-Datei zu optimieren. Dies verringert wiederum die Gesamtzeit, während der ein Server im schreibgeschützten Zustand sein muss.

  • Optimieren Sie Ihr Schema. Strukturieren Sie Ihre Daten so, dass keine Fremdschlüssel verwendet werden. Exportieren Sie die Daten nach Möglichkeit in der Reihenfolge des Primärschlüssels.
  • Optimieren Sie Ihre Ressourcen. Starten Sie nach Möglichkeit Ihre neue Datenbank mit genügend RAM, um das gesamte Dataset zu unterstützen. Außerdem kann die Verwendung von SSDs für Ihren Datenbankspeicher Ihren Datendurchsatz erheblich erhöhen. SSDs ermöglichen im Vergleich zu mechanischen Laufwerken mehr Ein-/Ausgabevorgänge pro Sekunde (Input/Output Operations per Second, IOPS). Google Cloud-SSDs erhöhen mit zunehmender Laufwerksgröße auch die IOPS-Anzahl. Dies bedeutet, dass sich die zusätzlichen Kosten und der überdimensionierte Speicherplatz eines größeren Laufwerks möglicherweise lohnen, da Sie von zusätzlichen IOPS profitieren.
  • Optimieren Sie das Monitoring. Eine robuste Monitoringlösung zur Erkennung von Problemen mit der alten oder neuen Datenbank kann für eine Migration sehr nützlich sein. Sie können beispielsweise Cloud Monitoring und das MySQL-Plug-in verwenden. Mit einer Monitoringlösung können Sie Probleme frühzeitig erkennen, das normale Datenbankverhalten nachvollziehen und die neue Datenbank mit der Referenzversion Ihrer vorherigen Datenbank vergleichen.

Große Datenbanken exportieren und importieren

Der mysqldump-Prozess funktioniert schnell bei Datenbanken, die kleiner als 10 GB sind. Wenn Sie Datenbanken importieren, die größer als 10 GB sind, müssen Sie möglicherweise erweiterte Strategien verwenden, um die Ausfallzeit der Datenbank während der endgültigen Umstellung zu minimieren.

Schema und Daten in Unterabschnitten exportieren

Eine Strategie besteht darin, das Datenbankschema und die Daten in Abschnitten ohne Sekundärschlüssel zu exportieren. Auf diese Weise können Sie die Sekundärschlüssel anhand von ALTER TABLE-Anweisungen am Ende der Migration hinzufügen. Mit diesem Ansatz exportieren Sie verschiedene Tabellensätze anhand ihrer Schlüsselbeziehungen in verschiedene Dateien. Anschließend können Sie die MySQL-Importprozesse parallel von einer Compute Engine-Instanz ausführen. Eine Möglichkeit zum Exportieren von Daten für den parallelen Import besteht darin, die Exportdateien selbst zu bearbeiten. Dies kann jedoch zeitaufwendig und fehleranfällig sein.

Zeitstempel nutzen

Wenn eine Ihrer Tabellen Zeitstempelspalten verwendet, können Sie eine Funktion des Befehls mysqldump verwenden, mit dem Sie eine WHERE-Klausel angeben können. So können Sie Daten mit Zeitstempel über mehrere Importe in Cloud SQL laden.

Wenn Sie für die endgültige Migrationsumstellung bereit sind, können Sie mit dieser Methode dann nur diejenigen Zeilen in der Quelldatenbank exportieren, die sich seit dem letzten Export geändert haben. Wenn Sie keine Tabellen mit Zeitstempeln haben und den Tabellen in der Quelldatenbank eine Zeitstempelspalte hinzufügen möchten, können Sie in jede Quelltabelle einen MySQL-Trigger einfügen, um den Zeitstempel bei jeder Änderung einer Zeile festzulegen.

Ein Problem bei dieser Methode ist das Tracking gelöschter Zeilen. In der Zeitstempelspalte werden nur Zeilen erfasst, die sich durch INSERT- oder UPDATE-Anweisungen geändert haben. Zeilen, die gelöscht werden, werden aus der Tabelle entfernt. Daher können Sie Zeilen, die nach der anfänglichen Migration gelöscht wurden, nur dann über einen Zeitstempel suchen, wenn Ihre Anwendung und Datenbank mit einem Mechanismus zum vorläufigen Löschen erstellt wurden. Bei dieser Methode setzen Sie eine is_deleted-Spalte auf "true", statt über eine DELETE-Anweisung anzugeben, dass eine Zeile gelöscht werden soll. Alternativ können Sie eine Tabelle erstellen, um gelöschte Zeilen für jede Ihrer realen Tabellen zu verfolgen, und einen passenden on_delete-Trigger, der gelöschte Zeilen in die Tabelle für das Tracking von Löschvorgängen einfügt. In der letzten Phase der Migration können Sie die erforderlichen DELETE-Anweisungen erstellen, um diese Zeilen aus Ihrer Cloud SQL-Instanz zu entfernen.

Exportdateien prüfen

Wenn Sie Ihre Exportdateien manuell ändern oder Exporte aus verschiedenen Tabellen durchführen, sollten Sie prüfen, ob Ihre Daten korrekt exportiert wurden.

Exportdateien vergleichen

Eine Möglichkeit, die exportierten Daten zu prüfen, ist die Implementierung einer inaktiven Testdatenbank. Sie können eine inaktive Testdatenbank erstellen, indem Sie eine aktuelle Produktionssicherung in einer neuen, eigenständigen Datenbankinstanz wiederherstellen. Anschließend stellen Sie die Datei mysqldump in der neuen inaktiven Testdatenbank wieder her. Als Nächstes können Sie Ihre stufenweise mysqldump-Prozedur testen und diese dann parallel in einer weiteren inaktiven Testdatenbank wiederherstellen. Dadurch erhalten Sie zwei identische Kopien der Datenbank. Sie können die Daten dann überprüfen. Führen Sie dazu den Befehl mysqldump für die beiden inaktiven Testdatenbanken aus und vergleichen Sie sie mit den Daten. Dafür können Sie den Befehl diff oder ein Tool zum Vergleichen von Dateien nutzen.

Das folgende Diagramm veranschaulicht diese Sequenz und zeigt die während des Prozesses erstellten Artefakte.

Sequenz und Artefakte zur Überprüfung von Exportdateien

Hochstufung externer Replikate

Die zweite Option für die Migration Ihrer MySQL-Datenbank ist die Hochstufung externer Replikate. Bei dieser Strategie erstellen Sie eine Replikatdatenbank und legen Ihre vorhandene Datenbank als primäre Datenbank fest. Sie warten, bis die beiden Datenbanken synchronisiert sind, und stufen dann Ihre MySQL-Replikatdatenbank als primäre Datenbank hoch. Durch diesen Prozess minimieren Sie Datenbankausfälle im Zusammenhang mit der Datenbankmigration.

Voraussetzungen

Wenn Sie die Migrationsmethode zur Hochstufung externer Replikate verwenden möchten, müssen zwei zusätzliche Voraussetzungen erfüllt sein: Ein Replikationsnutzer muss erstellt und die GTID-Replikation muss aktiviert sein.

Replikationsnutzer erstellen

Bestimmte MySQL-Versionen, einschließlich der in den Beispielen in diesem Dokument verwendeten Version 5.7, speichern den Nutzernamen und das Passwort aller zur Replikation verwendeten Nutzerkonten im Klartext in den Logs der primären Datenbank. Wenn Sie Ihr root-Nutzerkonto für die Replikation verwenden, speichern Sie Ihr root-Passwort in Ihren Nur-Text-Logs. Die Verwendung eines root-Nutzers für die Replikation stellt also ein Sicherheitsrisiko dar.

Es empfiehlt sich, ein völlig separates Konto für die Replikation zu erstellen, um das Risiko der Manipulation anderer Aspekte der Datenbank zu reduzieren. Das neue Konto sollte nur die erforderlichen Berechtigungen für den Replikationsprozess haben. Dieses Konto sollte außerdem so eingeschränkt sein, dass die Replikation nur von der IP-Adresse der primären Datenbank aus möglich ist.

GTID konfigurieren

In Ihrer Quelldatenbank muss die GTID-Replikation aktiviert sein, um eine Migration mit Hochstufung externer Replikate durchführen zu können. Wenn Sie die Replikation in Ihrer Quelldatenbank nicht konfiguriert haben, ist die GTID-Replikation möglicherweise nicht aktiviert.

Eine globale Transaktions-ID (GTID) ist eine eindeutige Kennung, die jeder Transaktion zugeordnet ist, für die auf dem primären Datenbankserver ein Commit durchgeführt wurde. Diese IDs werden verwendet, um den Replikationsprozess zwischen einem Replikat und einer primären Datenbank zu erstellen.

Neue Instanzen von Cloud SQL for MySQL verwenden standardmäßig die GTID-Replikation. Da Sie dies nicht deaktivieren können, sind bestimmte SQL-Anweisungen und -Vorgänge nicht zulässig. Weitere Informationen finden Sie unter Unterschiede zwischen Cloud SQL und den MySQL-Standardfunktionen und dem Artikel zu MySQL-Einschränkungen für die Replikation mit GTIDs.

Übersicht über die Migration mit Hochstufung externer Replikate

Im Vergleich zu einer Export/Import-Migration kann die Migration mit Hochstufung externer Replikate deutlich einfacher sein. Cloud SQL kann diesen Prozess automatisieren, wenn Sie alle zuvor beschriebenen Voraussetzungen erfüllt haben. Für den automatisierten Migrationsworkflow ist weiterhin ein Export/Import-Prozess erforderlich, aber einige der manuellen Schritte entfallen aufgrund der Automatisierung.

Der automatisierte Migrationsworkflow unterstützt die folgenden Szenarien:

  • Migration von lokalen Instanzen zu Cloud SQL
  • Migration von einem anderen Cloudanbieter zu Cloud SQL
  • Migration von einem Google Cloud-Projekt zu einem anderen Google Cloud-Projekt

Gehen Sie während des automatisierten Migrationsworkflows so vor:

  1. Geben Sie Details zu Ihrer Datenquelle an.
  2. Erstellen Sie ein Cloud SQL-Lesereplikat.
  3. Synchronisieren Sie das Lesereplikat mit der Quelle.
  4. Stufen Sie das Cloud SQL-Lesereplikat zur primären Instanz hoch.

Details zur Datenquelle angeben

Wenn Sie den automatisierten Migrationsworkflow mit Cloud SQL ausführen, geben Sie einen Referenznamen für die Datenquelle an. Dieser Name bezieht sich auf die Daten in der Migration und muss nicht mit dem tatsächlichen Namen der Quelle übereinstimmen.

Außerdem geben Sie die öffentliche IP-Adresse und den Port der Quelldatenbank an. Prüfen Sie, ob Ihre Cloud SQL-Datenbank eine direkte Verbindung zur Quelldatenbank über eine IPv4-Adresse hat. Außerdem müssen Sie dafür sorgen, dass alle Firewalls oder Sicherheits-Appliances zum Schutz der Quelldatenbank so konfiguriert sind, dass Verbindungen von der IP-Adresse der neuen Cloud SQL-Datenbank möglich sind.

Außerdem müssen Sie für den automatisierten Migrationsworkflow die Anmeldedaten des MySQL-Replikationsnutzers und die MySQL-Version angeben, die Sie migrieren möchten. Dies ist erforderlich, um sich beim Server zu authentifizieren und im nächsten Schritt eine sichere Übertragung zu ermöglichen. Sie können auch SSL/TLS-Optionen nach Bedarf konfigurieren.

Cloud SQL-Lesereplikat erstellen

Wenn Sie den automatisierten Migrationsworkflow ausführen, legen Sie Optionen zum Erstellen der neuen Cloud SQL-Instanz in Google Cloud fest. Dazu sind einige Schritte erforderlich:

  • Datenbankinstanz-ID festlegen
  • Google Cloud-Region und -Zone auswählen
  • Instanztyp auswählen
  • Speichertyp des Laufwerks auswählen
  • Gesamtspeicherkapazität auswählen. Wir empfehlen, automatische Speichererweiterungen zu aktivieren. Mit dieser Option können Sie Ihre Datenbank nach Bedarf erweitern und das Risiko verringern, nicht genügend Datenbankspeicherplatz zu haben.

Schließlich geben Sie einen Link zu dem Snapshot an, den Sie in Cloud Storage gespeichert haben. Achten Sie darauf, dass sich die neuesten Exportdateien in einem Cloud Storage-Bucket befinden, der sich im selben Projekt wie die Cloud SQL-Instanz befindet.

Lesereplikat mit der Quelle synchronisieren

Nachdem Sie den Migrationsprozess gestartet haben, wird die neue Cloud SQL-VM gestartet und beginnt mit der Replikation aus der Quelle. Wenn die Synchronisierung abgeschlossen ist, können Sie die Daten in der Datenbank vergleichen, um zu bestätigen, dass die Replikation abgeschlossen ist. Sie können auch mit dem Benchmarking beginnen, um die Leistung der Cloud SQL-Datenbank mit den Anforderungen Ihrer Anwendung und der zuvor gemessenen Referenzleistung Ihrer Quelldatenbank zu vergleichen.

Lesereplikat als primäre Instanz hochstufen

Beim Replizieren der Daten versetzen Sie die alte Datenbank in den Lesemodus. Dadurch werden Schreibvorgänge in die Datenbank verhindert und es wird gewährleistet, dass während des Hochstufungsprozesses keine Daten geändert werden. Anschließend aktualisieren Sie den Anwendungscode oder die DNS-Einträge wie zuvor beschrieben so, dass der neue Endpunkt in Cloud SQL unterstützt wird.

Wenn sich die Quelldatenbank im Lesemodus befindet und Ihre Anwendung mit der neuen Cloud SQL-Endpunktadresse aktualisiert wurde, können Sie die neue Datenbankinstanz in Cloud SQL aufrufen und das Replikat zum primären Server hochstufen. Durch diesen Hochstufungsprozess werden Schreibvorgänge auf der neu hochgestuften primären Cloud SQL-Instanz automatisch wieder aktiviert.

Nachdem Sie das Replikat zum primären Server hochgestuft haben, kann Ihre Datenbank unabhängig von der Datenbankgröße eine Ausfallzeit von mehreren Minuten aufweisen. Dies ist die Zeit, die Cloud SQL benötigt, um alle Aufgaben und Konfigurationsarbeiten auszuführen, die zum Hochstufen der Datenbank erforderlich sind.

Wenn die Hochstufung abgeschlossen ist, wird Ihre primäre Datenbank in Cloud SQL ausgeführt und die Migration ist abgeschlossen. Dies ist ein guter Zeitpunkt, um weitere Leistungstests in Bezug auf die Anforderungen der Anwendung und die Referenzleistung der Quelldatenbank durchzuführen. Wenn Sie die neuen Leistungsbenchmarks für Cloud SQL haben, können Sie weitere Datenbankoptimierungen planen.

Optimierung nach der Migration

Nach Abschluss der Migration können Sie Ihre Cloud SQL-Datenbank unabhängig von Ihrer Migrationsmethode so optimieren:

  • Passen Sie die Größe Ihrer VM entsprechend an. Durch die Analyse Ihrer Monitoringdaten können Sie feststellen, ob Sie eine VM mit einer anderen Größe für die Datenbank auswählen müssen. Möglicherweise können Sie die Kosten reduzieren, wenn Sie eine kleinere Instanz verwenden. Umgekehrt funktioniert Ihre Datenbank auf einer größeren VM mit mehr Ressourcen möglicherweise besser.
  • Fügen Sie weitere Indexe hinzu. Wenn Ihre Datenbank von zusätzlichen Indexen oder anderen Optimierungsoptionen profitieren könnte, können Sie diese nach Abschluss der Migration hinzufügen.
  • Aktivieren Sie zusätzlich das Logging von Transaktionen. Auf der Server-Logging-Ebene können Sie sich die Vorteile anschauen, die die Aktivierung des binären Loggings oder anderer erweiterter Logging-Optionen mit sich bringt.
  • Aktivieren Sie für die Migrationsmethode zur Hochstufung externer Replikate das binäre Logging wieder und nutzen Sie die automatischen Sicherungen. Nach der Migration mit Hochstufung von Replikaten werden automatische Sicherungen in Cloud SQL deaktiviert, da das binäre Logging deaktiviert ist.

Nächste Schritte