Es gibt verschiedene Möglichkeiten, in Cloud SQL zu MySQL zu migrieren. Die Migrationsstrategie für eine bestimmte Quelle hängt von mehreren Faktoren ab, u. a. von der Datenbankgröße, den Erwartungen an die Ausfallzeit und der Erfahrung der Entwickler, die die Migration durchführen. Sehen wir uns einige der gängigsten Migrationsstrategien an.

Wenn Sie über eine kleine Datenbank migrieren, die nur wenige Gigabyte groß ist oder statische Daten enthält, besteht der einfachste Ansatz darin, einen Dump der Datenbank über diemysqldump zu nehmen. Laden Sie die Dumpdatei in Cloud Storage hoch und importieren Sie sie in eine Cloud SQL-Instanz. Folgen Sie dazu der Anleitung im Artikel Mit SQL-Dump exportieren und importieren. Dateien.

Da die Dumpdateien logische SQL-Anweisungen enthalten, können Sie die Dumpdateien vor dem Laden in Cloud Storage bearbeiten. Aufgrund bestimmter Cloud SQL-Einschränkungen sollten Sie jedoch nichts in der Dumpdatei einfügen, die einen Import beeinträchtigen könnte, wie in den Best Practices zum Importieren und Exportieren von Daten aufgeführt.

Bei der Migration vieler MySQL-Instanzen oder größerer Migrationen ist der Datenbank-Migrationsdienst (DMS) die bessere Wahl. Dieser Dienst bietet eine Vielzahl von Migrationspfaden, einschließlich Pfaden für homogene und heterogene Migrationen zu MySQL sowie Unterstützung für SQL Server und PostgreSQL als Migrationsziele.

Für die meisten mittleren bis großen Datenbankmigrationen mit DMS sollte dies ausreichen. Situationen, in denen DMS möglicherweise nicht geeignet sind, umfassen sehr große Datenbanken (z. B. mehrere TB) oder wenn Sie MySQL-Entwickler mit Replikationswissen haben und eine genauere Kontrolle über die Datenbank bevorzugen Migrationsprozess mit nativer MySQL-Replikation

Wenn die Minimierung von Ausfallzeiten während der Migration Priorität hat und Sie erfahrene MySQL-Entwickler in Ihrem Team haben, ist das Replizieren von einer externen Quelle (ES) mit nativer, binärer logbasierter Replikation eine Option. Bei dieser Methode wird ein Referenz-Snapshot Ihrer Datenbank mit einer Methode wie einem Cloud Storage-Import importiert.

Anschließend konfigurieren Sie die MySQL-Replikation von der Quellinstanz zur Cloud SQL-Zielinstanz mithilfe einer Reihe vordefinierter gespeicherter Prozeduren, die bereits in der Cloud SQL-Instanz verfügbar sind. Eine vollständige Anleitung finden Sie im Artikel: Replikation aus großen externen Datenbanken mit einem benutzerdefinierten Import einrichten.

Ein wichtiges Detail bei der Verwendung der binären logbasierten Replikation für die Migration besteht darin, dass binäre Logs auf der Quellinstanz verfügbar bleiben, bis sie von der Cloud SQL-Zielinstanz nicht mehr benötigt werden. Wenn Sie MySQL lokal oder selbstverwaltet ausführen, können Parameter wie expire_logs_days so konfiguriert werden, dass das Löschen von binären Logs gesteuert wird. Für andere verwaltete Cloud-Anbieterdienste gibt es jedoch eigene Einschränkungen hinsichtlich der Aufbewahrung binärer Logs.

Mit dem Amazon Relational Database Service (RDS) können Sie beispielsweise die Aufbewahrungsdauer binärer Logs über einen gespeicherten Prozedurnamen mysql.rds_set_configuration konfigurieren. So ist die Aufbewahrung bis zu sieben Tage möglich. In den meisten Fällen reichen sieben Tage für die meisten kleinen bis mittelgroßen Migrationen von RDS zu Cloud SQL aus. In solchen Fällen können Nutzer einen gut dokumentierten Prozess nutzen, bei dem ein verwaltetes RDS-Replikat erstellt wird. Machen Sie dann etwas, um die Replikation zu durchbrechen, z. B. das Replikat beschreibbar zu machen und eine Zeile zu löschen oder eine Art von "Giftpille" auf die primäre Instanz einzufügen, die in das binäres Log gelangt und die Replikation unterbricht. Die RDS-Automatisierung löscht keine binären Logs, solange sie vom Replikat benötigt werden. Es scheint allerdings ein Gesamtlimit von 30 Tagen zu geben, bevor RDS einen fehlerhaften Replikationsstream „beendet“.

Eine weitere Problemumgehung besteht darin, mit dem mysqlbinlog-Client Binärlogs auf eine andere MySQL-Zwischeninstanz herunterzuladen, um ein vorzeitiges Löschen der Binärlogs zu verhindern. In RDS gibt es beispielsweise eine gespeicherte Prozedur namens mysql.rds_set_configuration, mit der Sie eine Aufbewahrungsdauer in Stunden festlegen können, um sicherzustellen, dass binäre Logs für den Download lang auf dem Host bleiben. In diesem Fall müssen Sie keine MySQL-Instanz als Vermittler einrichten, da ein Server wie eine MySQL-Instanz zum Speichern und Weiterleiten vorhanden ist, z. B. ein „Binlog-Server“. Binärlogs.

MySQL ist unter den gängigsten relationalen Datenbanksystemen insofern einzigartig, als es mehrere steckbare Speicher-Engines unterstützt. Ursprünglich unterstützte MySQL eine einzelne Speicher-Engine, die als MyISAM bezeichnet wurde, und bis MySQL 8.0, haben die meisten Systemtabellen diese Speicher-Engine verwendet. MyISAM bot jedoch keine Unterstützung für Transaktionen und war bei einem plötzlichen Systemabbruch oder Datenbankabsturz nicht absturzsicher.

Seitdem ist InnoDB zur De-facto-Speicher-Engine für die meisten MySQL-Nutzertabellen geworden, da diese Architektur absturzsicher ist und Transaktionen unterstützt. In der MySQL-Community gibt es jedoch sowohl in lokalen als auch bei anderen Cloud-Anbietern gängige Speicher-Engines, z. B.:

• ARCHIV: Speichert Daten zu Archivierungszwecken in einem stark komprimierten Format
• CSV: Speichert Daten in einem kommagetrennten Format (CSV) und wird zum Logging von Tabellen für das allgemeine und langsame Abfragelog verwendet
• MEMORY: Speichert Tabellen im Arbeitsspeicher

Im Fall von Cloud SQL benötigen wir eine transaktions- und absturzsichere Speicher-Engine, die wertschöpfende Features wie Replikation und Wiederherstellung zu einem bestimmten Zeitpunkt unterstützt. Daher müssen alle Nutzertabellen, die zu Cloud SQL migriert werden, die InnoDB-Speicher-Engine verwenden oder während des Migrationsprozesses in InnoDB konvertiert werden.

Dies ist besonders wichtig, wenn die native MySQL-Replikation von einer externen Quelle zu Cloud SQL erfolgt. In Cloud SQL können Nutzer keine MyISAM-Tabellen direkt auf einer Cloud SQL-Instanz über DDL-Befehle (Data Definition Language) wieTABELLE ERSTELLEN können derzeit MyISAM-Tabellen von einer externen Quelle in Cloud SQL repliziert werden.

Allerdings können diese importierten MyISAM-Tabellen in Cloud SQL später bei Vorgängen wie Replikation, Wiederherstellung zu einem bestimmten Zeitpunkt und Failover zu Stabilitäts- und Zuverlässigkeitsproblemen führen. Aus diesem Grund wird empfohlen, alle MyISAM-Nutzertabellen vor der Migration in InnoDB zu konvertieren. 

Mit der folgenden Abfrage werden alle MyISAM-Tabellen außerhalb des Systems aufgelistet.

Als verwalteter Dienst erlaubt MySQL für Cloud SQL keine SUPER-Berechtigung für Nutzerkonten. Dies ist eine Abkehr von den meisten lokalen Installationen von MySQL, die einen Root-Nutzer mit einer solchen Berechtigung ermöglichen. Ebenso geben die meisten anderen Cloud-Anbieter diese SUPER-Berechtigung nicht in einer verwalteten MySQL-Umgebung an.

Unabhängig davon, was der Fall ist, erhalten Nutzer von Cloud SQL einen MySQL-Standardnutzer mit dem Namen „root'@'%“, der über die meisten von MySQL bereitgestellten Berechtigungen verfügt, mit Ausnahme derjenigen, die sich auf die Fähigkeit von Google auswirken würden, den Dienst zu verwalten, wie z. B. die oben genannten SUPER sowie FILE und SHUTDOWN. Weitere Informationen zu den in Cloud SQL bereitgestellten Nutzungsrechten finden Sie in der Dokumentation zu MySQL-Nutzern.

Prüfen Sie bei der Vorbereitung der Migration alle Nutzerkonten auf der Quellinstanz. Führen Sie beispielsweise den Befehl SHOW GRANTS für jeden Nutzer aus, um die aktuellen Berechtigungen zu prüfen und zu sehen, ob Berechtigungen in Cloud SQL eingeschränkt sind. Ebenso können Sie mit dem pt-show-grants-Tool von Percona die Zuteilungen auflisten.

Einschränkungen für Nutzerberechtigungen in Cloud SQL können Migrationen betreffen, wenn Datenbankobjekte mit dem Attribut DEFINER migriert werden. Dies gilt häufig für gespeicherte Prozeduren, Trigger, benutzerdefinierte Funktionen und Ansichten. Wenn der Definierende ein Datenbankobjekt auf der Quellinstanz ein Nutzer mit einer Berechtigung ist, die in Cloud SQL nicht unterstützt wird, kann dies während oder nach der Migration ein Problem sein.

Beispielsweise kann eine gespeicherte Prozedur über eine Super-Privileg-Definition für SQL-Befehle wie das Ändern einer globalen Variablen verfügen, die in Cloud SQL nicht zulässig ist. In solchen Fällen kann es erforderlich sein, den Code der gespeicherten Prozedur neu zu schreiben oder nicht tabellenbasierte Objekte wie gespeicherte Prozeduren als separaten Migrationsschritt zu migrieren.

Unsere Dokumentation enthält den Abschnitt MySQL-Import- und Migrationsjobs mit Metadaten mit der DEFINER-Klausel, in denen mehr über andere Probleme im Zusammenhang mit der Definieren-Klausel für Datenbankobjekte gesprochen wird.

Aufgrund der oben erwähnten Einschränkungen für Nutzerberechtigungen können Nutzer den Befehl SET GLOBAL nicht nativ aufrufen, um Datenbankparameter zu ändern. Stattdessen bietet Cloud SQL einen vordefinierten Satz von Flags, die über die UI Console, die GCloud CLI und die REST API geändert werden können.

Eine vollständige Liste der unterstützten Cloud SQL-Flags für MySQL finden Sie in unserer öffentlichen Dokumentation im Abschnitt Unterstützte Flags. Prüfen Sie vor der Migration zu Cloud SQL die Liste der unterstützten Flags im Vergleich zu den Flags, die derzeit in Ihrer Quellumgebung verwendet werden. Als Best Practice wird beispielsweise empfohlen, eine Cloud SQL-Testinstanz mit ähnlichen CPU- und Speichereinstellungen wie die Quellinstanz zu erstellen und GLOBALE VARIABLEN ANZEIGENsowohl auf der Quell- als auch auf der Cloud SQL-Instanz auszuführen und die Unterschiede zu vergleichen.

Zu den gängigen Flags, die lokal oder bei einem Cloud-Anbieter andere Einstellungen als Cloud SQL for MySQL haben können, gehören:

• Einstellungen für Zeichensätze und Sortierungen wie character_set_server und collation_server. Die Standardwerte können sich je nach Installation unterscheiden und zu Speicher- und Leistungsunterschieden führen. Zum Beispiel „latin1“ im Vergleich zu „utf8“.
• Einstellungen für binäre Logs, z. B. binlog_format. Cloud SQL unterstützt derzeit nur zeilenbasiertes Logging im binären Log.
• Erweiterte Replikationseinstellungen. Cloud SQL unterstützt beispielsweise keine Replikationsfilterparameter wie replicate-do-table und replicate-do-db.
• Erweiterte InnoDB-Einstellungen. In Cloud SQL können Sie die meisten InnoDB-bezogenen Parameter ändern, z. B. die Änderung der Größe des InnoDB-Pufferpools durch Ändern von innodb_buffer_pool_size. Möglicherweise gibt es jedoch einige detailliertere InnoDB-Einstellungen, die nicht in Cloud SQL oder mit anderen Standardeinstellungen als lokal oder bei anderen Cloud-Anbietern geändert werden können.