Bekannte Einschränkungen

Bevor Sie Ihre Datenbanken zu Cloud SQL migrieren, sollten Sie die bekannten Einschränkungen für dieses Migrationsszenario berücksichtigen.

Hinweis: Sie können auch Google Cloud Migration Center verwenden, um Lücken bei der Featureunterstützung zu ermitteln. Weitere Informationen finden Sie in der Migration Center Dokumentation unter Datenbanken ermitteln und importieren.

Bekannte Einschränkungen bei der Verwendung einer MySQL-Datenbank als Quelle sind:

• Wenn Sie verschlüsselte Datenbanken migrieren möchten, müssen Sie dem Database Migration Service die Verschlüsselungsschlüssel zur Verfügung stellen. Der 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, Amazon RDS-Ressourcen verschlüsseln und Kundenverwaltete Verschlüsselungsschlüssel (CMEK) konfigurieren.

• Die Migration zu MySQL 5.6, MySQL 8.4 oder MySQL 9.7 mit einer physischen Sicherungsdatei von Percona XtraBackup wird nicht unterstützt.

• Für Migrationen von MySQL 8.0 zu MySQL 8.4 und von MySQL 8.4 zu MySQL 9.7:

  • Für die Zieldatenbank muss das Flag local_infile auf ON gesetzt sein.
  • Das dedizierte Migrationskonto in der Quellinstanz darf nicht die BACKUP_ADMIN Berechtigung haben.

  Diese Überlegungen werden auch in den entsprechenden Abschnitten behandelt, z. B. auf der Seite Quelldatenbank konfigurieren.

• 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 die Inkompatibilitäten zu ermitteln, die Sie beheben müssen.

  • MySQL 9.7
  • MySQL 8.4
  • MySQL 8.0
  • MySQL 5.7

• Während der Phase des vollständigen Datendumps können Sie in der Quelldatenbank keine DDL-Vorgänge (Data Definition Language, Datendefinitionssprache) ausführen, z. B. ALTER TABLE, DROP TABLE oder TRUNCATE TABLE. Wenn Sie diese Vorgänge während der Phase des vollständigen Dumps ausführen, kann dies zu einem Metadaten-Deadlock führen, wodurch der Migrationsprozess fehlschlägt (mit dem Table definition has changed Fehler) oder nicht mehr reagiert (und Zeitüberschreitungsfehler wie ERROR: While 'Loading data': Dump timeout oder MySQL Error 2013 (HY000): Lost connection to MySQL server during query gemeldet werden). Sie können DDL-Änderungen in der Quelldatenbank während der CDC-Phase vornehmen. Weitere Informationen finden Sie in den folgenden Einträgen im Abschnitt zur Fehlerbehebung:

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• 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 Quelldatenbank für Amazon RDS konfigurieren und Amazon Aurora-spezifische Abschnitte.

• Der Database Migration Service kann keine Daten aus einer Amazon Aurora-Lesereplikatinstanz oder einer Oracle Cloud Infrastructure (OCI) MySQL-Lesereplikatinstanz migrieren, da Binärlogdateien nicht aus der Instanz abgerufen werden können. Weitere Informationen zu Amazon Aurora finden Sie im Abschnitt Amazon Aurora-spezifische Abschnitte.

• Bei der Migration von einem selbstverwalteten MySQL-Lesereplikat wird GTID nicht unterstützt. Sie müssen die Replikation auf Basis von Binärlogdateien und Positionen verwenden. Weitere Informationen finden Sie unter Migrationstypen und ‑phasen.

• Die MySQL-Systemdatenbank wird nicht im Rahmen der Servermigration migriert. Informationen zu Nutzerkonten, Anmeldungen und Rollen sind daher nicht enthalten.

• Sie können zwar bestimmte Datenbanken für die Migration auswählen, aber beim Migrieren mit dem Database Migration Service keine einzelnen Datenbankobjekte innerhalb einer Datenbank filtern oder auswählen (z. B. bestimmte Tabellen, Ansichten oder gespeicherte Prozeduren). Alle InnoDB-Tabellen und ‑Objekte aus den ausgewählten Datenbanken werden migriert, mit Ausnahme der folgenden Systemschemas: mysql, performance_schema, information_schema und sys. Bevor Sie mit der Migration beginnen, prüfen Sie, ob die Quelldatenbank keine Objekte enthält, die auf Tabellen in diesen Schemas verweisen. Andernfalls kann die Migration mit der ERROR 1109 (42S02): Unknown table in <schema name here> Meldung fehlschlagen. Weitere Informationen finden Sie unter Quelldatenbank konfigurieren und Probleme diagnostizieren.

• 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.

• Database Migration Service ist nicht mit MariaDB kompatibel.

• Sie müssen das Binärlogformat auf ROW setzen. Wenn Sie das Binärlog in einem anderen Format wie STATEMENT oder MIXED konfigurieren, kann die Replikation fehlschlagen. Verwenden Sie beispielsweise die Anweisung LOAD DATA IN FILE.

  Weitere Informationen zu dieser Einschränkung für die STATEMENT oder MIXED Formate

• Wenn Sie einen kontinuierlichen Migrationsjob mit einer eigenen Dumpdatei erstellen, verwenden Sie nicht das Dienstprogramm mysqldump 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. Informationen zum Konvertieren von Tabellen von MyISAM zu 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 Datendump-Parallelität

Mit der Datendump-Parallelität können Sie mit einem leistungsstarken Dumpmechanismus aus MySQL-Datenbanken migrieren, wodurch die Migrationsgeschwindigkeit erheblich verbessert wird. Beachten Sie bei der Verwendung der Datendump-Parallelität Folgendes:

• Die Datendump-Parallelität ist nur verfügbar, wenn Sie zu MySQL-Version 5.7, 8.0, 8.4 oder 9.7 migrieren.

• Zu Beginn des Datendumps sperrt der Database Migration Service kurz die 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

Hinweis: Verwenden Sie in Szenarien, in denen es nicht möglich ist, die Quelldatenbank zu sperren, stattdessen ein Lesereplikat als Quelldatenbank. Informationen zur Migration von Lesereplikaten in Amazon RDS finden Sie unter Migration von RDS MySQL.

Einschränkungen für Migrationen zu vorhandenen Zielinstanzen

• Die vorhandene Zielinstanz darf 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 der vorhandenen Ziel instanz auftreten, löschen Sie die Datenbanken in der Zielinstanz und versuchen Sie es noch einmal. Weitere Informationen finden Sie unter Zusätzliche Daten aus der 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) in der Quellinstanz aktiviert sein.
• Sie können Cloud SQL for MySQL-Lesereplikate nicht als Zielinstanz für die Migration verwenden.
• Für Terraform-Nutzer: Der Database Migration Service ändert die Einstellungen für Sicherung und Wiederherstellung der 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. Um Platz für weitere zu schaffen, können Migrationsjobs (einschließlich abgeschlossener) und Verbindungsprofile gelöscht werden.