Übersicht
Bevor Sie Ihre Datenbanken zu Cloud SQL migrieren, sollten Sie die bekannten Einschränkungen für dieses Migrationsszenario berücksichtigen.
Bekannte Einschränkungen bei Verwendung einer MySQL-Datenbank als Quelle:
Die Migration zu MySQL 5.6 oder MySQL 8.4 mit einer physischen Sicherungsdatei von Percona XtraBackup wird nicht unterstützt.
Migrationen von MySQL 8.0 zu MySQL 8.4: Für Migrationen von 8.0 zu 8.4 gelten folgende zusätzliche Überlegungen:
- Für Ihre Zieldatenbank muss das Flag
local_infileaufONgesetzt sein. - Das dedizierte Migrationskonto in der Quellinstanz darf nicht die
BACKUP_ADMINBerechtigung haben.
Diese Überlegungen werden auch in den entsprechenden Abschnitten behandelt, z. B. auf der Seite Quelldatenbank konfigurieren.
- Für Ihre Zieldatenbank muss das Flag
Wenn Sie zwischen verschiedenen Hauptversionen von MySQL migrieren (z. B. von MySQL 8.0 zu MySQL 8.4), müssen Sie mögliche Inkompatibilitäten beheben, um eine reibungslose Migration ohne Probleme mit der Datenkonsistenz zu gewährleisten.
Wenn Sie sich auf eine Migration zwischen Versionen vorbereiten, prüfen Sie die von Cloud SQL for MySQL unterstützten Funktionen sowie die Versionshinweise für Ihre Ziel-Hauptversion, um zu ermitteln, welche Inkompatibilitäten Sie beheben müssen.
Nehmen Sie während der Phase des vollständigen Datendumps keine Änderungen an der Datendefinitionssprache (Data Definition Language, DDL) vor, z. B. an Tabellendefinitionen. DDL-Änderungen, die vorgenommen werden, bevor der Migrationsjob in die CDC-Phase übergeht, können dazu führen, dass der Migrationsjob fehlschlägt. Weitere Informationen finden Sie unter Probleme diagnostizieren:
Table definition has changedFehler.Wenn die Quelle Amazon RDS MySQL, Amazon Aurora MySQL oder eine Quelle ist, die keine SUPERUSER-Berechtigungen gewährt, sind zusätzliche Schritte für eine erfolgreiche Migration erforderlich, einschließlich einer kurzen Ausfallzeit für Schreibvorgänge in der Quelle. Weitere Informationen finden Sie in den Abschnitten zu Amazon RDS und Amazon Aurora.
Database Migration Service kann keine Daten aus einer Amazon Aurora-Lesereplikatinstanz eines MySQL-Datenbankclusters migrieren, da Binärlogdateien nicht aus der Instanz abgerufen werden können. Weitere Informationen finden Sie im Abschnitt zu Amazon Aurora.
Die MySQL-Systemdatenbank wird nicht im Rahmen der Servermigration migriert. Informationen zu Nutzerrollen sind daher nicht enthalten.
Sie können bestimmte Datenbanken auswählen, wenn Sie mit Database Migration Service migrieren. Alle Tabellen und Schemas aus den ausgewählten Datenbanken werden migriert, mit Ausnahme der folgenden Systemschemas:
mysql,performance_schema,information_schemaundsys. Prüfen Sie vor Beginn der Migration, ob Ihre Quelldatenbank keine Objekte enthält, die auf Tabellen in diesen Schemas verweisen. Andernfalls kann die Migration mit derERROR 1109 (42S02): Unknown table in <schema name here>Meldung fehlschlagen. Weitere Informationen finden Sie unter Quelldatenbank konfigurieren und Probleme diagnostizieren.Wenn für verschlüsselte Datenbanken von Kunden verwaltete Verschlüsselungsschlüssel erforderlich sind, um die Informationen in den Datenbanken zu entschlüsseln, und Database Migration Service keinen Zugriff auf die Schlüssel hat, können die Datenbanken nicht migriert werden.
Database Migration Service unterstützt die Migration von Daten aus verschlüsselten Amazon Aurora- oder Amazon RDS-Datenbanken, da diese Datenbanken die Entschlüsselung transparent in ihren Diensten verarbeiten. Weitere Informationen finden Sie unter Amazon Aurora-Ressourcen verschlüsseln und Amazon RDS-Ressourcen verschlüsseln.
Während der Migration befindet sich die Cloud SQL-Zieldatenbank im schreibgeschützten Modus, um Änderungen an der Datenbank zu verhindern, die den Migrationsprozess oder die Datenintegrität beeinträchtigen könnten. Nachdem das Ziel hochgestuft wurde, kann darauf geschrieben werden.
Derzeit ist Database Migration Service nicht mit MariaDB kompatibel.
Sie müssen das Binärlogformat auf
ROWsetzen. Wenn Sie das Binärlog in einem anderen Format wieSTATEMENToderMIXEDkonfigurieren, kann die Replikation fehlschlagen. Verwenden Sie beispielsweise die AnweisungLOAD DATA IN FILE.Weitere Informationen zu dieser Einschränkung für die Formate
STATEMENToderMIXED.Wenn Sie einen kontinuierlichen Migrationsjob erstellen mit einer eigenen Dumpdatei, verwenden Sie nicht das
mysqldumpDienstprogramm aus MySQL Version 5.7.36. Weitere Informationen finden Sie in der MySQL-Dokumentation unter Fehler 105761.InnoDB ist die einzige unterstützte Speicher-Engine für Cloud SQL. Eine Migration mit MyISAM kann zu Dateninkonsistenzen führen und erfordert eine Datenvalidierung. Hinweise zur Konvertierung von Tabellen von MyISAM in InnoDB finden Sie in der MySQL-Dokumentation.
Die Verbindungsmethode über Private Service Connect-Schnittstellen wird nur für die Migration zu vorhandenen Zielinstanzen unterstützt. Wenn Sie eine private IP-Verbindung verwenden und zu einer neuen Zielinstanz migrieren möchten, verwenden Sie VPC-Peering.
Überlegungen zur Parallelität des Datendumps
Mit der Parallelität des Datendumps können Sie mit einem leistungsstarken Dumpmechanismus aus MySQL-Datenbanken migrieren, wodurch die Migrationsgeschwindigkeit erheblich verbessert wird. Beachten Sie bei der Verwendung der Parallelität des Datendumps Folgendes:
Die Parallelität des Datendumps ist derzeit nur verfügbar, wenn Sie zu MySQL Version 5.7 oder 8 migrieren.
Zu Beginn des Datendumps sperrt Database Migration Service kurz Ihre Quelldatenbank, sodass sie vorübergehend nicht für Schreibvorgänge verfügbar ist. Die Sperrdauer hängt von der Anzahl der Tabellen in der Quelldatenbank ab:
Anzahl der Tabellen Ungefähre Sperrdauer 100 1 Sekunde 10.000 9 Sekunden 50.000 49 Sekunden
Einschränkungen für Migrationen zu vorhandenen Zielinstanzen
- Ihre vorhandene Zielinstanz kann nur Standardsystemdatenbanken enthalten
die automatisch eingerichtet werden, wenn Sie die Zielinstanz erstellen.
Die Migration zu vorhandenen Zielinstanzen
die Nutzerdaten enthalten (z. B. Tabellen in Systemschemas oder Datenbanken)
wird nicht unterstützt.
Wenn Probleme aufgrund zusätzlicher Daten in Ihrer vorhandenen Ziel instanz auftreten, löschen Sie die Datenbanken in Ihrer Zielinstanz und versuchen Sie es noch einmal mit dem Migrationsjob. Weitere Informationen finden Sie unter Zusätzliche Daten aus Ihrer vorhandenen Zielinstanz löschen.
- Sie können nur einen Migrationsjob pro Zielinstanz konfigurieren.
- Sie können nur zu eigenständigen Cloud SQL-Instanzen migrieren. Die Migration zu externen Serverreplikaten wird nicht unterstützt.
- Für die Migration zu einer Cloud SQL-Instanz mit einem Lesereplikat muss die Protokollierung der globalen Transaktions-ID (GTID) für Ihre Quellinstanz aktiviert sein.
- Sie können Cloud SQL for MySQL-Lesereplikate nicht als Zielinstanz für die Migration verwenden.
- Für Terraform-Nutzer: Database Migration Service ändert die Einstellungen für Sicherung und Wiederherstellung Ihrer Zielinstanz. Dadurch können sich die Einstellungen der Zielinstanz von der Terraform Konfiguration unterscheiden, die Sie für die Bereitstellung verwendet haben. Wenn dieses Problem auftritt, folgen Sie der Anleitung unter Probleme diagnostizieren.
Kontingente
- Es können immer bis zu 2.000 Verbindungsprofile und 1.000 Migrationsjobs gleichzeitig vorhanden sein. Wenn Platz für weitere Jobs und Profile benötigt wird, können Migrationsjobs (einschließlich bereits abgeschlossene) und Verbindungsprofile gelöscht werden.