Probleme mit MySQL diagnostizieren

Während der Laufzeit des Migrationsjobs können Fehler auftreten.

  • Einige Fehler, z. B. ein falsches Passwort in der Quelldatenbank, können behoben werden. In diesem Fall wird der Migrationsjob automatisch fortgesetzt.
  • Einige sind nicht behebbar, z. B. ein Verlust der Binlog-Position. In diesem Fall muss der Migrationsjob von Anfang an neu gestartet werden.

Wenn ein Fehler auftritt, ändert sich der Status des Migrationsjobs in Failed und der Unterstatus spiegelt den letzten Status vor dem Fehler wider.

Wenn Sie einen Fehler beheben möchten, rufen Sie den fehlgeschlagenen Migrationsjob auf, um den Fehler zu sehen, und folgen Sie der Anleitung in der Fehlermeldung.

Wenn Sie weitere Details zum Fehler aufrufen möchten, rufen Sie Cloud Monitoring über den Link im Migrationsjob auf. Die Logs werden nach dem jeweiligen Migrationsjob gefiltert.

In der folgenden Tabelle finden Sie einige Beispiele für Probleme und wie sie behoben werden können:

Problem Mögliche Ursache Lösungsvorschlag
Die Einstellungen der Zieldatenbank unterscheiden sich von der Terraform-Konfiguration, die zum Bereitstellen der Datenbank verwendet wurde. Dieses Problem wird manchmal auch als Konfigurationsabweichung bezeichnet. Wenn Sie zu einer vorhandenen Zieldatenbank migrieren, ändert der Database Migration Service bestimmte Einstellungen Ihrer Zieldatenbank, um den Migrationsjob auszuführen. Sie müssen die Einstellungen, die Sie in Ihrer Terraform-Konfiguration verwenden, noch einmal anwenden, nachdem Sie den Migrationsjob hochgestuft haben. Weitere Informationen finden Sie unter Terraform-Konfigurationsabweichung.
Fehlermeldung: Error processing table {table_name}: MySQL Error 1118 (42000): Row size too large (>8126). Tabellen, die VARCHAR-Spalten verwenden, können Zeilen enthalten, die die von InnoDB (der in MySQL verwendeten Standardspeicher-Engine) zulässige maximale Größe überschreiten. Sie können die Blockierung Ihres Migrationsjobs aufheben, indem Sie Spalten in BLOB oder TEXT konvertieren oder das Flag innodb_strict_mode vorübergehend auf off setzen. Weitere Informationen finden Sie unter Fehler 1118: Zeilengröße zu groß.
Der Migrationsjob ist während der Phase mit dem anfänglichen Dump mit der folgenden Fehlermeldung fehlgeschlagen:
ERROR 1064 (42000) at {line_number}: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near {reserved_word} at {line_number}. 		Dieses Problem tritt bei der Migration zwischen MySQL-Versionen auf. Entitäten in Ihrer MySQL-Quellversion verwenden möglicherweise Wörter, die in der MySQL-Version, zu der Sie migrieren möchten, nicht zulässig sind.

In MySQL 5.7 können Sie beispielsweise das Wort function in Spaltennamen verwenden. In MySQL 8.0 ist function jedoch ein reserviertes Wort, sodass die Zieldatenbank Ihre Quellen nicht parsen kann.

 Benennen Sie die in der Fehlermeldung referenzierten Quelldatenbankobjekte um oder setzen Sie sie in Backticks (``), um die Syntax zu maskieren. Versuchen Sie dann noch einmal, den Migrationsjob auszuführen.
Fehlermeldung: ERROR 1109 (42S02): Unknown table in <schema name here> Mit Database Migration Service werden die Systemschemata mysql, performance_schema, information_schema, ndbinfo und sys nicht migriert.

Ihr Migrationsjob kann fehlschlagen, wenn die Quelldatenbank Objekte enthält, die auf Tabellen aus einem dieser Schemas verweisen.

Suchen Sie in Ihrer Quelldatenbank nach Objekten, die auf Tabellen in einem der Systemschemata verweisen, die nicht migriert werden. Weitere Informationen finden Sie unter FEHLER 1109 (42S02): Unbekannte Tabelle in <schema name here>.
Fehlermeldung: Unknown table 'COLUMN_STATISTICS' in information_schema (1109) Relevant für Szenarien mit manuellen Datenbank-Dumps mit mysqldump.

MySQL-Datenbanken in Versionen vor 8 haben die Tabelle COLUMN_STATISTICS nicht. Das Dienstprogramm mysqldump in Version 8 und höher versucht standardmäßig, diese Tabelle zu exportieren. Der Export schlägt fehl, weil die Spalte nicht vorhanden ist.

 Verwenden Sie das Flag --column-statistics=0, wenn Sie mysqldump verwenden.
Fehlermeldung: Specified key was too long; max key length is 767 bytes. In der Quelldatenbankinstanz ist möglicherweise die Variable innodb_large_prefix festgelegt. Setzen Sie das Flag innodb_large_prefix beim Erstellen der Zielinstanz auf ON oder aktualisieren Sie die vorhandene Zielinstanz mit dem Flag.
Fehlermeldung: Table definition has changed. Während des Dumpprozesses wurden DDL-Änderungen (Data Definition Language, Datendefinitionssprache) vorgenommen. Vermeiden Sie DDL-Änderungen während des Dumpprozesses.
Fehlermeldung: While 'Loading data': Dump timeout. Möglicherweise wird die Zeitüberschreitung durch ein Verbindungsproblem verursacht. Prüfen Sie die Netzwerkverbindung zur Quelldatenbank. Beispielanleitungen finden Sie unter Verbindungsprobleme beheben.
Wenn während des Dump-Prozesses Änderungen an der Datendefinitionssprache (DDL) vorgenommen wurden, kann Database Migration Service aufgrund einer Metadatensperre hängen bleiben. Prüfen Sie Ihre Quelldatenbank auf Prozesse, die im Status Waiting for table metadata lock hängen geblieben sind. Wenn Sie Prozesse mit diesem Status finden, empfehlen wir, den Migrationsjob neu zu starten. Nehmen Sie nach dem Neustart während der Phase des vollständigen Dumps keine DDL-Änderungen vor. Sie können ein Beispielskript verwenden, um zu prüfen, ob DDL-Vorgänge beendet wurden.
MySQL Error 2013: (HY000): Lost connection to MySQL server during query Möglicherweise wird die Zeitüberschreitung durch ein Verbindungsproblem verursacht. Prüfen Sie die Netzwerkverbindung zur Quelldatenbank. Beispielanleitungen finden Sie unter Verbindung debuggen.
Wenn während des Dump-Prozesses Änderungen an der Datendefinitionssprache (DDL) vorgenommen wurden, kann es sein, dass Database Migration Service in einer Metadatensperre hängen bleibt. Prüfen Sie Ihre Quelldatenbank auf Prozesse, die im Status Waiting for table metadata lock hängen geblieben sind. Wenn Sie Prozesse mit diesem Status finden, empfehlen wir, den Migrationsjob neu zu starten. Nehmen Sie nach dem Neustart während der Phase des vollständigen Dumps keine DDL-Änderungen vor. Sie können ein Beispielskript verwenden, um zu prüfen, ob DDL-Vorgänge beendet wurden.
Fehlermeldung: Timeout waiting for no write traffic on source: context deadline exceeded. Möglicherweise wird die Zeitüberschreitung durch ein Verbindungsproblem verursacht. Prüfen Sie die Netzwerkverbindung zur Quelldatenbank. Beispielanleitungen finden Sie unter Verbindungsprobleme beheben.
Wenn während des Dump-Vorgangs Änderungen an der Datendefinitionssprache (Data Definition Language, DDL) vorgenommen wurden, kann es sein, dass Database Migration Service in einer Metadatensperre hängen bleibt. Prüfen Sie Ihre Quelldatenbank auf Prozesse, die im Status Waiting for table metadata lock hängen geblieben sind. Wenn Sie Prozesse mit diesem Status finden, empfehlen wir, den Migrationsjob neu zu starten. Nehmen Sie nach dem Neustart während der Phase des vollständigen Dumps keine DDL-Änderungen vor. Sie können ein Beispielskript verwenden, um zu prüfen, ob DDL-Vorgänge beendet wurden.
Fehlermeldung: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Möglicherweise gibt es in der Quelldatenbank ein Ereignis, eine Ansicht, eine Funktion oder eine Prozedur, die super user@localhost (z. B. root@localhost) verwendet. Dies wird von Cloud SQL nicht unterstützt. Weitere Informationen zur Verwendung von DEFINER in Cloud SQL.
Fehlermeldung: Definer user 'x' does not exist. Please create the user on the replica. Der Nutzer ist auf dem Replikat nicht vorhanden. Weitere Informationen zur Verwendung von DEFINER in Cloud SQL.
Fehlermeldung: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost. In der Quelldatenbank ist ein DEFINER vorhanden, das im Replikat nicht vorhanden ist. Weitere Informationen zur Verwendung von DEFINER in Cloud SQL
Fehlermeldung: Lost connection to MySQL server during query when dumping table. Die Quelldatenbank war möglicherweise nicht mehr erreichbar oder der Dump enthielt zu große Pakete. Probieren Sie diese Vorschläge aus.
Fehlermeldung: Got packet bigger than 'max_allowed_packet' bytes when dumping table. Das Paket war größer als der eingestellte zulässige Wert. Manuellen Dump mit der Option max_allowed_packet verwenden.
Die erste Datenmigration war erfolgreich, aber es werden keine Daten repliziert. Möglicherweise gibt es in Konflikt stehende Replikations-Flags. Prüfen Sie diese Flag-Einstellungen.
Die erste Datenmigration war erfolgreich, aber die Datenreplikation funktioniert nach einer Weile nicht mehr. Dafür gibt es viele Gründe. Probieren Sie diese Vorschläge aus.
Fehlermeldung: mysqld check failed: data disk is full. Das Datenlaufwerk der Zielinstanz ist voll. Erhöhen Sie die Laufwerkgröße der Zielinstanz. Sie können die Laufwerkgröße manuell erhöhen oder die automatische Speichererweiterung aktivieren.
Fehler beim Herstellen einer Verbindung zur Quelldatenbankinstanz. Es ist ein Verbindungsproblem zwischen der Quelldatenbankinstanz und der Zielinstanz aufgetreten. Folge der Anleitung im Artikel Verbindungsprobleme beheben.
Die Migration von einer verwalteten Datenbank (Amazon RDS/Aurora) wird nicht gestartet. Für die Migration von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen ist zu Beginn der Migration eine kurze Ausfallzeit erforderlich. Folgen Sie der Anleitung in diesem Artikel.
Das Binlog ist in der Quelldatenbank falsch konfiguriert. Die Binlog-Definitionen sind falsch. Achten Sie bei kontinuierlichen MySQL-Migrationsjobs darauf, die erforderlichen Binlog-Definitionen zu beachten.
Die Dump-Datei wurde nicht gefunden. DMS kann die angegebene Dump-Datei nicht finden. Dies kann passieren, wenn die Dumpdatei am angegebenen Speicherort nicht gefunden wird.
  1. Prüfen Sie den Dump-Pfad, um sicherzustellen, dass dort eine geeignete Datei vorhanden ist, oder ändern Sie den Pfad.
  2. Wenn Sie den Pfad ändern, verwenden Sie eine PATCH-Anfrage, damit der Job ihn verwendet.
  3. Starten Sie den Migrationsjob neu.
Die Replikation kann nicht fortgesetzt werden, da die Binlog-Position verloren gegangen ist. Die Binlog-Position ging verloren und der Migrationsjob konnte nicht fortgesetzt werden. Dieser Fehler kann auftreten, wenn der Replikationsprozess für längere Zeit pausiert wird, was dazu führt, dass die Binlog-Position verloren geht. Migrationsjobs sollten nicht für Zeiträume angehalten werden, die sich der Aufbewahrungsdauer für Binlog-Dateien nähern. Starten Sie den Migrationsjob neu.
Wenn Sie zu einer vorhandenen Zielinstanz migrieren, wird die folgende Fehlermeldung angezeigt: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job. Ihre Cloud SQL-Zielinstanz enthält zusätzliche Daten. Sie können nur zu vorhandenen Instanzen migrieren, die leer sind. Weitere Informationen finden Sie unter Bekannte Einschränkungen. Stufen Sie die Zielinstanz zu einer Lese-/Schreibinstanz hoch, entfernen Sie die zusätzlichen Daten und versuchen Sie es noch einmal mit dem Migrationsjob. Weitere Informationen finden Sie unter Zusätzliche Daten aus der vorhandenen Zielinstanz löschen.
Der Migrationsjob konnte nicht ausgeführt werden, weil die Versionen der Quell- und Zieldatenbank nicht kompatibel sind. Die angegebene Quelldatenbankversion ist nicht mit der Zieldatenbankversion kompatibel. Achten Sie darauf, dass die Version der Zieldatenbank mit der Version der Quelldatenbank übereinstimmt oder eine Hauptversion höher ist. Erstellen Sie dann einen neuen Migrationsjob.
Fehlermeldung: Unable to connect to source database server. Database Migration Service kann keine Verbindung zum Quelldatenbankserver herstellen. Prüfen Sie, ob die Quell- und die Zieldatenbankinstanz miteinander kommunizieren können und ob Sie alle erforderlichen Voraussetzungen erfüllt haben, die beim Definieren der Einstellungen für den Migrationsjob angezeigt wurden.
Fehlermeldung: Timeout waiting for no write traffic on source. Bei der Migration von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen kommt es zu Beginn der Migration zu einer kurzen Ausfallzeit. Folgen Sie der Anleitung unter Von RDS MySQL ohne SUPERUSER-Berechtigungen migrieren.
Fehlermeldung: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist. Möglicherweise gibt es eine Inkonsistenz zwischen dem Wert des Flags lower_case_table_names für die Quelldatenbank und dem Wert des Flags für die Cloud SQL-Zielinstanz. Legen Sie den Wert des Flags für die Cloud SQL-Instanz so fest, dass er mit dem Wert des Flags für die Quelldatenbank übereinstimmt.
Fehlermeldung: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}. Einige Objekte in der Quelldatenbank, z. B. Ansichten, Funktionen, gespeicherte Prozeduren oder Trigger, verweisen auf eine Tabelle, die nicht mehr in der Datenbank vorhanden ist. Prüfen Sie, ob diese Objekte vorhanden sind. Wenn dies der Fall ist, löschen Sie entweder die Objekte aus der Quelldatenbank oder fügen Sie die Tabelle, auf die die Objekte verweisen, der Quelldatenbank hinzu.
Fehlermeldung: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries. Sie haben ein falsches Passwort für die Quellinstanz angegeben. Oder die Quellinstanz erzwingt eine SSL-Verbindung, der Migrationsjob ist jedoch nicht für die Verwendung von SSL-Zertifikaten konfiguriert.

Prüfen Sie, ob Nutzername, Passwort und SSL-Einstellungen für die Quellinstanz korrekt sind, indem Sie den mysql-Client verwenden.

Wenn die Quellinstanz Cloud SQL ist, lesen Sie den Abschnitt SSL/TLS anfordern, um zu prüfen, ob SSL/TLS für TCP-Verbindungen erforderlich ist.

Die Replikationsverzögerung ist durchgehend hoch.

Die Schreiblast ist für das Replikat zu hoch. Eine Replikationsverzögerung tritt auf, wenn der Cloud SQL for MySQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können für ein bestimmtes Schema zu einer vorübergehenden oder dauerhaften hohen Replikationsverzögerung führen. Einige typische Ursachen für Replikationsverzögerungen sind:

  • Langsame Abfragen werden auf dem Replikat ausgeführt. Suchen Sie diese und korrigieren Sie sie.
  • Es wird dringend empfohlen, dass alle Tabellen einen eindeutigen Primärschlüssel haben. Jede Aktualisierung einer Tabelle, die diesen Schlüssel nicht hat, führt zu vollständigen Tabellenscans im Replikat, was zu Replikationsverzögerungen führt.
  • Abfragen wie DELETE ... WHERE field < 50000000 führen bei der zeilenbasierten Replikation zu einer Replikationsverzögerung, da sich eine große Anzahl von Aktualisierungen auf dem Replikat ansammelt.

Hier einige mögliche Lösungen:

Fehlermeldung: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. In der Quelldatenbank werden möglicherweise Zeichensätze oder Sortierungen verwendet, die vom ausgewählten Cloud SQL-Replikat nicht unterstützt werden. Ein Beispiel ist AWS Aurora Version 2.x, die mit MySQL 5.7 kompatibel ist. Diese Version unterstützt jedoch die Sortierung utf8mb4_0900_as_ci, die in Cloud SQL for MySQL 5.7 nicht unterstützt wird.
  • Wenn die Migration während der vollständigen Dump-Phase fehlschlägt, prüfen Sie die Definition der Quelltabelle, um festzustellen, ob nicht unterstützte Zeichensätze oder Sortierungen verwendet werden. Aktualisieren Sie nach Möglichkeit auf unterstützte Zeichensätze oder Sortierungen.
  • Wenn die Migration während der CDC-Phase fehlschlägt, prüfen Sie den Replikatstatus, suchen Sie das Binlog, das den Fehler verursacht, und untersuchen Sie die Quelldatenbank und die Anwendung, um die SQL-Anweisungen zu finden, die die Zeichensätze oder Sortierungen verwenden. Aktualisieren Sie dann auf unterstützte Zeichensätze oder Sortierungen.

Fehler 1108: Zeilengröße zu groß

Tabellen mit Spalten, in denen Strings mit variabler Länge gespeichert werden, können Zeilen enthalten, die die maximale InnoDB-Zeilengröße überschreiten.

Lösungsvorschlag

Quelltabellenschema anpassen

Dieses Problem kann immer wieder auftreten, wenn Sie INSERT-Anweisungen in Tabellen ausführen, die das Limit für die maximale Zeilengröße überschreiten. Um zukünftige Probleme zu vermeiden, sollten Sie Ihre Tabellen anpassen, bevor Sie die Migration noch einmal versuchen:

  • Ändern Sie die Tabelle ROW_FORMAT in DYNAMIC oder COMPRESSED, indem Sie die folgende Abfrage ausführen: 
    ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
    Dabei gilt:
    • TABLE_NAME ist der Name der Tabelle, deren Zeilen das maximale Zeilenlimit überschreiten.
    • FORMAT_NAME ist DYNAMIC oder COMPRESSED
    Beispiel: 
    ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
  • Zeilendaten in BLOB oder TEXT konvertieren Eine Möglichkeit, diesen Vorgang auszuführen, ist die Funktion CONVERT().
Strikten InnoDB-Modus deaktivieren

Wenn Sie das Schema der Quelltabelle nicht anpassen können, können Sie die InnoDB-Validierung vorübergehend deaktivieren, um den Migrationsjob abzuschließen. Das Problem kann bei zukünftigen Schreibversuchen in die Datenbank wieder auftreten. Es ist daher am besten, das Tabellenschema anzupassen, wenn dies möglich ist.

So deaktivieren Sie die InnoDB-Validierung vorübergehend, um den Migrationsjob abzuschließen:

Wenn…Dann…
Wenn Sie zu einer neuen Zielinstanz migrieren
  1. Erstellen Sie den Migrationsjob neu.
  2. Klicken Sie am Ende des Schritts Ziel definieren auf Optionale Konfigurationen anzeigen.
  3. Wählen Sie im Bereich Flags das Flag innodb_strict_mode aus und setzen Sie es auf Off.
  4. Setzen Sie nach Abschluss der Migration das Flag innodb_strict_mode auf On. Weitere Informationen finden Sie in der Cloud SQL for MySQL-Dokumentation unter Datenbank-Flags konfigurieren.
Wenn Sie zu einer vorhandenen Zielinstanz migrieren
  1. Rufen Sie in Cloud SQL die Zielinstanz auf und setzen Sie das Flag innodb_strict_mode auf Off. Weitere Informationen finden Sie in der Cloud SQL for MySQL-Dokumentation unter Datenbank-Flags konfigurieren.
  2. Migrationsjob neu erstellen
  3. Setzen Sie nach Abschluss der Migration das Flag innodb_strict_mode auf On. Weitere Informationen finden Sie in der Cloud SQL for MySQL-Dokumentation unter Datenbank-Flags konfigurieren.

Zusätzliche Daten aus der vorhandenen Zielinstanz löschen

Wenn Sie zu einer vorhandenen Zielinstanz migrieren, erhalten Sie die folgende Fehlermeldung: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.

Dieses Problem kann auftreten, wenn Ihre Zielinstanz zusätzliche Daten enthält. Sie können nur zu vorhandenen Instanzen migrieren, die leer sind. Bekannte Einschränkungen

Lösungsvorschlag

Löschen Sie zusätzliche Daten aus der Zielinstanz und starten Sie den Migrationsjob noch einmal. Gehen Sie dazu so vor:

  1. Beenden Sie den Migrationsjob.
  2. An diesem Punkt befindet sich Ihre Cloud SQL-Zielinstanz im Modus read-only. Stufen Sie die Zielinstanz hoch, um Schreibzugriff zu erhalten.
  3. Verbindung zur Cloud SQL-Zielinstanz herstellen
  4. Entfernen Sie zusätzliche Daten aus den Datenbanken der Zielinstanz. Ihr Ziel kann nur Systemkonfigurationsdaten enthalten. Zieldatenbanken dürfen keine Nutzerdaten wie Tabellen enthalten. Es gibt verschiedene SQL-Anweisungen, die Sie in Ihren Datenbanken ausführen können, um Nicht-Systemdaten zu finden, z. B.: 
    SELECT schema_name FROM information_schema.SCHEMATA
WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
  5. Migrationsjob starten

Konfigurationsdrift in Terraform

Wenn Sie zu einer vorhandenen Zieldatenbank migrieren, ändert Database Migration Service bestimmte Einstellungen der Zieldatenbank, um den Migrationsjob auszuführen. Bei Datenbanken, die mit Terraform bereitgestellt wurden, kann diese Interaktion zu einer Konfigurationsabweichung führen, bei der sich die tatsächliche Konfiguration der Zieldatenbank von der in Ihren Terraform-Dateien festgelegten Konfiguration unterscheidet.

Lösungsvorschlag

Versuchen Sie nicht, die Terraform-Konfiguration noch einmal anzuwenden, wenn der Migrationsjob ausgeführt wird. Sie können die erforderliche Konfiguration nach dem Hochstufen der Zieldatenbank sicher anpassen. Database Migration Service nimmt die folgenden Änderungen an Ihrer Cloud SQL-Zielinstanz vor: Konfigurationsabweichungen sind zu erwarten, wenn Ihre Terraform-Konfiguration Einstellungen für eine dieser Funktionen enthält. Wenn Sie die Konfiguration der Zieldatenbank korrigieren müssen, warten Sie, bis der Migrationsjob abgeschlossen ist und die Zieldatenbank hochgestuft wurde. Führen Sie dann folgende Schritte aus: 1. Führen Sie den Befehl „terraform plan“ aus, um eine Vorschau Ihrer Änderungen zu sehen. 1. Führen Sie den Befehl „terraform apply“ aus, um die Einstellungen der Zieldatenbank neu anzupassen.

ERROR 1109 (42S02): Unknown table in <schema name here>

Migrationsjobs schlagen mit der folgenden Meldung fehl: ERROR 1109 (42S02): Unknown table in <schema name here> , z. B. ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema.

Mögliche Ursache

Database Migration Service migriert die Systemschemas mysql, performance_schema, information_schema, ndbinfo und sys nicht (siehe Bekannte Einschränkungen). Ihr Migrationsjob kann fehlschlagen, wenn die Quelldatenbank Objekte enthält, die auf Tabellen aus einem dieser Schemas verweisen.

Lösungsvorschlag

Prüfen Sie Ihre Quelldatenbank auf Objekte, die auf Tabellen aus den Systemschemas verweisen. Führen Sie in Ihrer Quelldatenbank die folgenden Abfragen aus: 
# Query to check routines or functions definitions.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check view definitions.
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check trigger definitions.
SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

# Query to check constraint definitions.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'
 Wenn diese Abfragen Ergebnisse zurückgeben, sollten Sie die entsprechenden Codeobjekte löschen und die Migration noch einmal durchführen.

Unbekannte Tabelle „COLUMN_STATISTICS“ in information_schema

Wenn Sie das Dienstprogramm mysqldump Version 8 oder höher ausführen, um eine MySQL-Datenbankversion vor Version 8 zu exportieren, tritt der folgende Fehler auf: Unknown table 'COLUMN_STATISTICS' in information_schema (1109).

Mögliche Ursache

MySQL-Datenbanken in Versionen vor 8 haben die Tabelle COLUMN_STATISTICS nicht. Das mysqldump-Tool in Version 8 und höher versucht, diese Tabelle standardmäßig zu exportieren. Der Export schlägt fehl, weil die Spalte nicht vorhanden ist.

Lösungsvorschlag

Fügen Sie dem Befehl mysqldump das Flag --column-statistics=0 hinzu, um die Tabelle COLUMN_STATISTICS aus dem Export zu entfernen. Weitere Informationen finden Sie unter MySQL-Datenbank mit mysqldump exportieren.

Der angegebene Schlüssel war zu lang. Die maximale Schlüssellänge beträgt 767 Byte.

Der Fehler Specified key was too long; max key length is 767 bytes. wird angezeigt.

Mögliche Ursache

In der Quelldatenbank ist möglicherweise die Variable innodb_large_prefix festgelegt. Dadurch sind Indexschlüsselpräfixe mit mehr als 767 Byte zulässig. Der Standardwert für MySQL 5.6 ist OFF.

Lösungsvorschlag

Setzen Sie beim Erstellen der Zieldatenbank das Flag innodb_large_prefix auf ON oder aktualisieren Sie die vorhandene Zieldatenbank mit dem Flag.

Tabellendefinition hat sich geändert

Der Fehler Table definition has changed wird angezeigt.

Mögliche Ursache

Während des Dumpprozesses wurden DDL-Änderungen vorgenommen.

Lösungsvorschlag

Ändern Sie während des Dump-Prozesses keine Tabellen und nehmen Sie keine anderen DDL-Änderungen vor.Mit einem Script können Sie prüfen, ob DDL-Vorgänge beendet wurden.

Zugriff verweigert. Sie benötigen für diesen Vorgang mindestens eine der SUPER-Berechtigungen

Der Fehler Access denied; you need (at least one of) the SUPER privilege(s) for this operation wird angezeigt.

Mögliche Ursache

In der Quelldatenbank kann ein Ereignis, eine Ansicht, eine Funktion oder eine Prozedur vorhanden sein, die einen Superuser@localhost (z. B. root@localhost) verwendet. Dies wird von Cloud SQL nicht unterstützt.

Lösungsvorschlag

Weitere Informationen finden Sie in diesem Dokument zur Migration einer Datenbank mit DEFINER-Klauseln.

Fehlermeldung: Definer user 'x' does not exist. Please create the user on the replica.

Der Fehler Definer user 'x' does not exist. Please create the user on the replica. wird angezeigt.

Mögliche Ursache

Die Ursache ist, dass ein Nutzer in der Quelldatenbank mit der DEFINER-Klausel in der Replikatdatenbank nicht vorhanden ist.

Lösungsvorschlag

Weitere Informationen finden Sie in diesem Dokument zur Migration einer Datenbank mit DEFINER-Klauseln. Möglicherweise müssen Sie den Nutzer in der Replikatdatenbank erstellen.

Fehlermeldung: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost

Der Fehler ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost wird angezeigt.

Mögliche Ursache

Die Ursache ist, dass ein Nutzer in der Quelldatenbank mit der DEFINER-Klausel nicht in der Replikatdatenbank vorhanden ist und in den Objektdefinitionen in der Quelldatenbank auf diesen Nutzer verwiesen wird.

Lösungsvorschlag

Weitere Informationen finden Sie in diesem Dokument zur Migration einer Datenbank mit DEFINER-Klauseln. Möglicherweise müssen Sie einen oder mehrere Nutzer in der Replikatdatenbank erstellen.

Die Verbindung zu MySQL-Server wurde während der Abfrage beim Auslesen der Tabelle in eine Dumpdatei getrennt.

Der Fehler Lost connection to MySQL server during query when dumping table wird angezeigt.

Mögliche Ursache

  • Die Quelldatenbankinstanz ist möglicherweise von der Zielinstanz aus nicht mehr erreichbar.
  • Die Quelldatenbank enthält möglicherweise Tabellen mit großen Blobs oder langen Strings, für die max_allowed_packet in der Quelldatenbank auf einen größeren Wert festgelegt werden muss.

Lösungsvorschlag

  • Prüfen Sie, ob die Quelldatenbankinstanz aktiv und erreichbar ist.
  • Konfigurieren Sie das Flag max-allowed-packet im Migrationsjob und starten Sie den Migrationsjob dann neu. Sie können auch einen manuellen Dump mit der Option max_allowed_packet generieren, um die Daten zu sichern und mit der Dumpdatei zu migrieren.
  • Wenn Sie max_allowed_packet erhöhen, müssen Sie wahrscheinlich die Einstellungen net_read_timeout und net_write_timeout in der Quelldatenbank anpassen. Im Allgemeinen sollte der Wert erhöht werden, bis der Verbindungsfehler nicht mehr auftritt.

Beim Auslesen der Tabelle in eine Dumpdatei war ein Paket erhalten, das den Wert von „max_allowed_packet“' überschritten hat.

Der Fehler Got packet bigger than 'max_allowed_packet' bytes when dumping table wird angezeigt.

Mögliche Ursache

Das Paket war größer als der eingestellte zulässige Wert.

Lösungsvorschlag

Erstellen Sie einen Migrationsjob mit einem manuellen Dump mit der Option max_allowed_packet, um die Daten zu exportieren und mit der Dumpdatei zu migrieren.

Es werden keine Daten repliziert

Die erste Datenmigration war erfolgreich, aber es werden keine Daten repliziert.

Mögliche Ursache

Eine mögliche Ursache könnte sein, dass Ihre Quelldatenbank Replikations-Flags hat, die dazu führen, dass einige oder alle Datenbankänderungen nicht repliziert werden.

Lösungsvorschlag

Achten Sie darauf, dass die Replikations-Flags wie binlog-do-db, binlog-ignore-db, replicate-do-db oder replicate-ignore-db nicht widersprüchlich festgelegt sind.
Führen Sie den Befehl show master status in der Quelldatenbank aus, um die aktuellen Einstellungen aufzurufen.

Die erste Datenmigration war erfolgreich, aber die Datenreplikation hat nach einer Weile nicht mehr funktioniert

Die erste Datenmigration war erfolgreich, aber die Datenreplikation funktioniert nach einer Weile nicht mehr.

Mögliche Ursache

Dieses Problem kann viele Ursachen haben.

Lösungsvorschlag

  • Prüfen Sie die Replikationsmesswerte für Ihre Zielinstanz in Cloud Monitoring.
  • Die Fehler aus dem MySQL-E/A-Thread oder dem SQL-Thread finden Sie unter Cloud Logging in den mysql.err-Logdateien.
  • Der Fehler kann auch beim Herstellen einer Verbindung zur Zielinstanz auftreten. Führen Sie den Befehl SHOW REPLICA STATUS aus und suchen Sie in der Ausgabe nach den folgenden Feldern:
    • Replica_IO_Running
    • Replica_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

    Hinweis:SHOW REPLICA STATUS ist ein Alias, der in MySQL 8.0.22 eingeführt wurde. Verwenden Sie für frühere Versionen (MySQL 5.7, MySQL 8.0) den alten Alias des Statusbefehls. Weitere Informationen finden Sie in der MySQL-Dokumentation unter Status statement.

    Wenn Sie den Fehler fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error erhalten haben, kann das an einer unzureichenden Einstellung für die Aufbewahrung von Binärlogs in der Quellinstanz liegen.

    Wenn Sie den Fehler error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES erhalten haben, kann dies daran liegen, dass die Zielinstanz aufgrund eines Verbindungs- oder Authentifizierungsproblems keine Verbindung zur Quelle herstellen konnte.

mysqld-Prüfung fehlgeschlagen: Das Datenlaufwerk ist voll.

Der Fehler mysqld check failed: data disk is full wird angezeigt.

Mögliche Ursache

Das Datenlaufwerk der Zielinstanz ist wahrscheinlich voll.

Lösungsvorschlag

Erhöhen Sie die Laufwerksgröße der Zielinstanz.

Verbindung zur Quelldatenbank fehlgeschlagen

Fehler beim Herstellen einer Verbindung zur Quelldatenbank.

Mögliche Ursache

Es gab ein Verbindungsproblem zwischen der Quelldatenbankinstanz und der Zielinstanz.

Lösungsvorschlag

Folgen Sie der Anleitung im Artikel zur Fehlerbehebung bei Verbindungen.

Migration von einer verwalteten Datenbank (Amazon RDS/Aurora) wird nicht gestartet

Der Migrationsjob kann nicht gestartet werden.

Mögliche Ursache

Bei der Migration von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen ist zu Beginn der Migration eine kurze Ausfallzeit erforderlich.

Lösungsvorschlag

Binlog ist in der Quelldatenbank falsch konfiguriert

Sie sehen einen Fehler, der auf ein Problem mit den Binärlogs hinweist.

Mögliche Ursache

Dies kann bei kontinuierlichen MySQL-Migrationsjobs passieren, wenn die Binlog-Konfiguration in der Quelldatenbank falsch ist.

Lösungsvorschlag

Folgen Sie der Anleitung.

Fehler beim Lesen der bereitgestellten Dumpdatei

Sie sehen einen Fehler, der auf ein Problem mit der Dump-Datei hinweist.

Mögliche Ursache

DMS kann die angegebene Dump-Datei nicht finden.

Lösungsvorschlag

  1. Prüfen Sie den Dump-Pfad, um sicherzustellen, dass dort eine geeignete Datei vorhanden ist, oder ändern Sie den Pfad.
  2. Wenn Sie den Pfad ändern, verwenden Sie eine PATCH-Anfrage, damit der Job ihn verwendet.
  3. Starten Sie den Migrationsjob neu.

Replikation kann nicht fortgesetzt werden, da die Binlog-Position verloren gegangen ist

Die Binlog-Position ist verloren gegangen.

Mögliche Ursache

Dieser Fehler kann auftreten, wenn der Replikationsprozess für längere Zeit pausiert wird, was dazu führt, dass die Binlog-Position verloren geht. Migrationsjobs sollten nicht für Zeiträume angehalten werden, die sich der Aufbewahrungsdauer für Binlog-Dateien nähern.

Lösungsvorschlag

Starten Sie den Migrationsjob neu.

Fehler beim Ausführen des Migrationsjobs aufgrund inkompatibler Quell- und Zieldatenbankversionen

Die Datenbankversionen für die Quelle und das Ziel sind keine unterstützte Kombination.

Mögliche Ursache

Die angegebene Quelldatenbankversion ist nicht mit der Zieldatenbankversion kompatibel.

Lösungsvorschlag

Achten Sie darauf, dass die Zieldatenbankversion dieselbe oder eine Hauptversion höher als die Quelldatenbankversion ist, und erstellen Sie dann einen neuen Migrationsjob.

Verbindung zum Quelldatenbankserver kann nicht hergestellt werden

Der Fehler Unable to connect to source database server wird angezeigt.

Mögliche Ursache

Database Migration Service kann keine Verbindung zum Quelldatenbankserver herstellen.

Lösungsvorschlag

Prüfen Sie, ob die Quell- und Zieldatenbankinstanzen miteinander kommunizieren können. Prüfen Sie dann, ob Sie alle erforderlichen Voraussetzungen erfüllt haben, die beim Festlegen der Einstellungen für Ihren Migrationsjob angezeigt wurden.

Speicherplatznutzung der Cloud SQL-Zielinstanz sinkt auf null

Die Festplattennutzung sinkt während der Migration plötzlich auf null.

Mögliche Ursache

Beim Importieren der ursprünglichen Daten kann ein Fehler auftreten. In diesem Fall wird versucht, die Daten noch einmal zu laden. Bei diesem Vorgang werden zuerst die vorhandenen Daten in der Zielinstanz gelöscht. Daher sinkt die Festplattennutzung auf null. Anschließend wird versucht, die Daten neu zu laden.

Lösungsvorschlag

Rufen Sie den Log-Explorer auf und wählen Sie aus der Ressourcenliste Ihre Zielinstanz aus. Suchen Sie nach einer ähnlichen Logeintrag: DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again." Suchen Sie die Nachricht nach dem Text import failed: und versuchen Sie, das zugrunde liegende Problem zu beheben.