Bekannte Einschränkungen

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

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

Für die Verwendung einer MySQL-Datenbank als Quelle gelten unter anderem folgende bekannte Einschränkungen:

• Wenn Sie verschlüsselte Datenbanken migrieren möchten, müssen Sie die Verschlüsselungsschlüssel für Database Migration Service bereitstellen. 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 Percona XtraBackup-Sicherungsdatei wird nicht unterstützt.

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

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

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

• Wenn Sie zwischen MySQL-Hauptversionen 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 versionsübergreifende Migration vorbereiten, sollten Sie sich die von Cloud SQL for MySQL unterstützten Features sowie die Versionshinweise für Ihre Zielhauptversion ansehen, um festzustellen, welche Inkompatibilitäten Sie beheben müssen.

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

• Während der Phase des vollständigen Daten-Dumps können Sie keine DDL-Vorgänge (Data Definition Language, Datendefinitionssprache) wie ALTER TABLE, DROP TABLE, TRUNCATE TABLE in Ihrer Quelldatenbank ausführen. Wenn Sie diese Vorgänge während der Phase mit dem vollständigen Dump ausführen, kann dies zu einem Metadaten-Deadlock führen. Dadurch schlägt der Migrationsprozess fehl (mit dem Fehler Table definition has changed) oder reagiert nicht mehr (und meldet Zeitüberschreitungsfehler wie ERROR: While 'Loading data': Dump timeout oder MySQL Error 2013 (HY000): Lost connection to MySQL server during query). Sie können während der CDC-Phase DDL-Änderungen an Ihrer Quelldatenbank 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 Unterbrechung der Schreibvorgänge auf der Quelle. Weitere Informationen finden Sie in den Abschnitten Quelldatenbank für Amazon RDS konfigurieren und Amazon Aurora-spezifisch.

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

• Bei der Migration von einem selbstverwalteten MySQL-Lesereplikat wird GTID nicht unterstützt. Sie müssen die binäre Logdatei und die positionsbasierte Replikation 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 keine einzelnen Datenbankobjekte innerhalb einer Datenbank (z. B. bestimmte Tabellen, Ansichten oder gespeicherte Prozeduren) filtern oder auswählen, wenn Sie mit dem Database Migration Service migrieren. Alle InnoDB-Tabellen und -Objekte aus jeder ausgewählten Datenbank werden migriert, mit Ausnahme der folgenden Systemschemas: mysql, performance_schema, information_schema und sys. Prüfen Sie vor Beginn der Migration, ob Ihre Quelldatenbank Objekte enthält, die auf Tabellen in diesen Schemas verweisen. Andernfalls kann die Migration mit der Meldung ERROR 1109 (42S02): Unknown table in <schema name here> fehlschlagen. Weitere Informationen finden Sie unter Quelldatenbank konfigurieren und Probleme diagnostizieren.

• Während der Migration befindet sich die Cloud SQL-Zieldatenbank im Lesemodus, um Änderungen an der Datenbank zu verhindern, die den Migrationsprozess oder die Datenintegrität beeinträchtigen könnten. Nachdem das Ziel hochgestuft wurde, kann es beschrieben werden.

• Database Migration Service ist nicht mit MariaDB kompatibel.

• Sie müssen das Binärlogformat auf ROW festlegen. Wenn Sie das Binärlog in einem anderen Format wie STATEMENT oder MIXED konfigurieren, schlägt die Replikation möglicherweise fehl. Beispiel: Verwendung der LOAD DATA IN FILE-Anweisung.

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

• Wenn Sie einen kontinuierlichen Migrationsjob mit Ihrer 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 für 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 Parallelität von Datendumps können Sie MySQL-Datenbanken mit einem leistungsstarken Dump-Mechanismus migrieren, was die Migrationsgeschwindigkeit erheblich verbessert. Beachten Sie bei der Verwendung der Parallelität von Daten-Dumps Folgendes:

• Die Parallelität von Daten-Dumps ist nur bei der Migration zu MySQL-Versionen 5.7, 8.0, 8.4 oder 9.7 verfügbar.

• Zu Beginn des Daten-Dumps sperrt Database Migration Service die Quelldatenbank kurz, sodass sie vorübergehend nicht für Schreibvorgänge verfügbar ist. Die Dauer der Sperre hängt von der Anzahl der Tabellen in der Quelldatenbank ab:

  Anzahl der Tabellen	Ungefähre Sperrzeit
  100	1 Sekunde
  10K	9 Sekunden
  50.000	49 Sekunden

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

Einschränkungen für Migrationen zu vorhandenen Zielinstanzen

• Ihre vorhandene Zielinstanz darf nur Standardsystemdatenbanken enthalten, die beim Erstellen der Zielinstanz automatisch eingerichtet werden. 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 Zielinstanz 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 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 auf der Quellinstanz das Logging der globalen Transaktions-ID (GTID) 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 Sicherungs- und Wiederherstellungseinstellungen Ihrer Zielinstanz. Dies kann dazu führen, dass die Einstellungen der Zielinstanz von der Terraform-Konfiguration abweichen, 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 Sie Platz für weitere Migrationsjobs und Verbindungsprofile schaffen möchten, können Sie vorhandene (auch abgeschlossene) löschen.