Fehler beheben
Während der Laufzeit des Migrationsjobs können Fehler auftreten.
- Einige Fehler, z. B. ein ungültiges Passwort in der Quelldatenbank, sind wiederherstellbar. Dies bedeutet, dass diese Fehler behoben werden können und der Migrationsauftrag anschließend automatisch fortgesetzt wird.
- Einige sind nicht wiederherstellbar, z. B. ein verlorener Binlog-Speicherort. In diesem Fall muss der Migrationsjob von vorn gestartet werden.
Wenn ein Fehler auftritt, ändert sich der Status des Migrationsjobs in Failed und der Unterstatus entspricht dem letzten Status vor dem Fehler.
Wenn Sie einen Fehler beheben möchten, rufen Sie den fehlgeschlagenen Migrationsjob auf, um den Fehler anzuzeigen, und folgen Sie der Anleitung in der Fehlermeldung.
Weitere Informationen zum Fehler finden Sie in Cloud Monitoring. Klicken Sie dazu auf den Link zum Migrationsjob. Die Protokolle 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 auch als Konfigurationsabweichung bezeichnet. | Wenn Sie zu einer vorhandenen Zieldatenbank migrieren, ändert der Database Migration Service bestimmte Einstellungen der Zieldatenbank, um den Migrationsjob auszuführen. | Sie müssen die Einstellungen, die Sie in Ihrer Terraform-Konfiguration verwenden, nach dem Promoten des Migrationsjobs noch einmal anwenden. Weitere Informationen finden Sie unter Abweichungen bei Terraform-Konfigurationen. |
Fehlermeldung: Error processing table {table_name}: MySQL Error 1118
(42000): Row size too large (>8126). |
Tabellen mit VARCHAR-Spalten können Zeilen enthalten, die die von InnoDB (der in MySQL verwendeten Standard-Speicher-Engine) zulässige maximale Größe überschreiten. |
Sie können die Blockierung des 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 vollständigen Dumpphase 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.
In Entitäten in Ihrer Quell-MySQL-Version werden möglicherweise Wörter verwendet, 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 |
Benennen Sie die in der Fehlermeldung referenzierten Quelldatenbankobjekte um oder setzen Sie sie in Backticks (``), um die Syntax zu escapen. Wiederholen Sie den Migrationsjob, wenn der Vorgang abgeschlossen ist.
|
Fehlermeldung: ERROR 1109 (42S02): Unknown table in <schema name here> |
Der Database Migration Service migriert die Systemschemata mysql, performance_schema, information_schema, ndbinfo und sys nicht.
Der Migrationsjob schlägt möglicherweise fehl, wenn die Quelldatenbank Objekte enthält, die auf Tabellen aus einem dieser Schemas verweisen. |
Prüfen Sie Ihre Quelldatenbank auf Objekte, die auf Tabellen in den nicht migrierten Systemschemata verweisen. Weitere Informationen finden Sie unter Fehler 1109 (42S02): Unbekannte Tabelle in <schema name here>. |
Fehlermeldung: Unknown table 'COLUMN_STATISTICS' in information_schema (1109) |
Nur für manuelle Datenbankdump-Szenarien mit mysqldump relevant.MySQL-Datenbanken in Versionen vor 8 haben keine COLUMN_STATISTICS-Tabelle. Das Dienstprogramm |
Verwenden Sie das Flag --column-statistics=0, wenn Sie mysqldump verwenden. |
Fehlermeldung: Specified key was too long; max key length is 767 bytes. |
Für die 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: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. |
Es kann ein Ereignis, eine Ansicht, eine Funktion oder eine Prozedur in der Quelldatenbank mit superuser@localhost (z. B. root@localhost) vorhanden sein. 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 im 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, den es im Replikat nicht gibt. |
Weitere Informationen zur Verwendung von DEFINER in Cloud SQL finden Sie in diesem Artikel. |
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. | Verwenden Sie einen manuellen Dump mit der Option max_allowed_packet. |
| 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 Lösungsvorschlä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 gab ein Verbindungsproblem zwischen der Quelldatenbankinstanz und der Zielinstanz. | Folgen Sie der Anleitung im Artikel Verbindungsprobleme beheben. |
| Die Migration von einer verwalteten Datenbank (Amazon RDS/Aurora) wird nicht gestartet. | Die Migration von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen erfordert zu Beginn der Migration eine kurze Ausfallzeit. | Folgen Sie der Anleitung in diesem Artikel. |
| Der Binlog ist in der Quelldatenbank falsch konfiguriert. | Die Binlog-Definitionen sind falsch. | Beachten Sie bei fortlaufenden MySQL-Migrationsjobs die erforderlichen Binlog-Definitionen. |
| Die Dumpdatei konnte nicht gefunden werden. | DMS kann die angegebene Dumpdatei nicht finden. | Das kann passieren, wenn der Migrationsjob die Dumpdatei nicht am angegebenen Speicherort finden kann.
|
| Die Replikation kann nicht fortgesetzt werden, da die Binlog-Position verloren gegangen ist. | Die Binlog-Position wurde verloren und der Migrationsjob konnte nicht fortgesetzt werden. | Dieser Fehler kann auftreten, wenn der Replikationsprozess für einen längeren Zeitraum pausiert wird, wodurch die Binlog-Position verloren geht. Migrationsjobs sollten nicht für einen Zeitraum pausiert werden, der an die Aufbewahrungsdauer des Binlogs heranreicht. Starten Sie den Migrationsjob neu. |
Wenn Sie zu einer
bestehenden 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.
|
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. | Stellen Sie die Zielinstanz als Lese-/Schreibinstanz bereit, entfernen Sie die zusätzlichen Daten und versuchen Sie den Migrationsjob noch einmal. Weitere Informationen finden Sie unter Zusätzliche Daten aus Ihrer vorhandenen Zielinstanz löschen. |
| Fehler beim Ausführen des Migrationsjobs aufgrund inkompatibler Versionen von Quell- und Zieldatenbank. | Die angegebene Version der Quelldatenbank ist nicht mit der Version der Zieldatenbank kompatibel. | Achten Sie darauf, dass die Version der Zieldatenbank mit der Version der Quelldatenbank identisch ist oder eine Hauptversion darüber liegt. Erstellen Sie dann einen neuen Migrationsjob. |
Fehlermeldung: Unable to connect to source database server.
|
Database Migration Service kann keine Verbindung zum Quelldatenbankserver herstellen. | Achten Sie darauf, dass die Quell- und Zieldatenbankinstanzen miteinander kommunizieren können und dass 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.
|
Die Migration von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen führt zu einer kurzen Ausfallzeit zu Beginn der Migration. |
Folgen Sie der Anleitung unter Migration von RDS MySQL ohne SUPERUSER-Berechtigungen. |
Fehlermeldung: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.
|
Möglicherweise gibt es eine Abweichung zwischen dem Wert des lower_case_table_names-Flags für die Quelldatenbank und dem Wert des Flags für die Cloud SQL-Ziellininstanz. |
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 in der Datenbank nicht mehr vorhanden ist. | Prüfen Sie, ob diese Objekte vorhanden sind. Falls ja, löschen Sie die Objekte entweder 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. Möglicherweise erzwingt die Quellinstanz eine SSL-Verbindung, der Migrationsjob ist jedoch nicht für die Verwendung von SSL-Zertifikaten konfiguriert. | Prüfen Sie mit dem Wenn es sich bei der Quellinstanz um Cloud SQL handelt, lesen Sie den Hilfeartikel SSL/TLS erforderlich machen, 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 vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:
|
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. |
Die Quelldatenbank verwendet möglicherweise Zeichensätze oder Sortierungen, 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 utf8mb4_0900_as_ci-Sortierung, die in Cloud SQL for MySQL 5.7 nicht unterstützt wird. |
|
Fehler 1108: Zeilengröße zu groß
Tabellen mit Spalten, in denen Strings mit variabler Länge gespeichert werden, können Zeilen enthalten, die die Standardgröße der maximalen InnoDB-Zeile überschreiten.Lösungsvorschlag
Schema der Quelltabelle anpassen
Dieses Problem kann immer dann wieder auftreten, wenn Sie INSERT-Anweisungen in die Tabellen ausführen, die das maximale Zeilenlimit überschreiten. Um zukünftige Probleme zu vermeiden, sollten Sie Ihre Tabellen anpassen, bevor Sie die Migration noch einmal versuchen:
- Ändern Sie die Tabelle
ROW_FORMATinDYNAMICoderCOMPRESSED, indem Sie die folgende Abfrage ausführen:ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
- TABLE_NAME ist der Name der Tabelle, deren Zeilen die maximale Zeilengröße überschreiten.
- FORMAT_NAME ist
DYNAMICoderCOMPRESSED.
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- Zeilendaten in BLOB oder TEXT konvertieren Eine Möglichkeit dazu 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 der Datenbank wieder auftreten. Es empfiehlt sich daher, das Tabellenschema nach Möglichkeit anzupassen.
So deaktivieren Sie die InnoDB-Validierung vorübergehend, um den Migrationsjob abzuschließen:
| Wenn… | Dann… |
|---|---|
| Wenn Sie zu einer neuen Zielinstanz migrieren |
|
| Migration zu einer vorhandenen Zielinstanz |
|
Zusätzliche Daten aus der vorhandenen Zielinstanz löschen
Wenn Sie zu einer
bestehenden 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. Weitere Informationen finden Sie unter 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:
- Migrationsjob beenden
- Die Ziel-Cloud SQL-Instanz befindet sich derzeit im Modus
read-only. Zielinstanz hochstufen, um Schreibzugriff zu erhalten. - Verbindung zur Cloud SQL-Zielinstanz herstellen
- Entfernen Sie zusätzliche Daten aus den Datenbanken der Zielinstanz. Das Ziel kann nur Systemkonfigurationsdaten enthalten. Zieldatenbanken dürfen keine Nutzerdaten (z. B. Tabellen) enthalten. Es gibt verschiedene SQL-Anweisungen, die Sie in Ihren Datenbanken ausführen können, um nicht systemeigene Daten zu finden, z. B.:
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- Starten Sie den Migrationsjob.
Abweichungen in der Terraform-Konfiguration
Wenn Sie zu einer vorhandenen Zieldatenbank migrieren, ändert der Database Migration Service bestimmte Einstellungen der Zieldatenbank, um den Migrationsjob auszuführen. Bei mit Terraform bereitgestellten Datenbanken kann diese Interaktion zu einer Konfigurationsabweichung führen, bei der sich die tatsächliche Zieldatenbankkonfiguration von der in Ihren Terraform-Dateien festgelegten Konfiguration unterscheidet.Lösungsvorschlag
Versuchen Sie nicht, die Terraform-Konfiguration noch einmal anzuwenden, während der Migrationsjob ausgeführt wird. Sie können die erforderliche Konfiguration nach der Umstellung der Zieldatenbank problemlos anpassen. Der Database Migration Service nimmt die folgenden Änderungen an der Ziel-Cloud SQL-Instanz vor:- Die Sicherungskonfiguration ist auf die Standardwerte gesetzt.
- Die Wiederherstellung zu einem bestimmten Zeitpunkt wird auf die Standardwerte zurückgesetzt.
FEHLER 1109 (42S02): Unbekannte Tabelle 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
Der Database Migration Service migriert die Systemschemata mysql, performance_schema, information_schema, ndbinfo und sys nicht (siehe
Bekannte Einschränkungen).
Der Migrationsjob schlägt möglicherweise fehl, 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 Systemschemata verweisen. Führen Sie in der 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'
Unbekannte Tabelle „COLUMN_STATISTICS“ in information_schema
Wenn Sie das Dienstprogramm mysqldump Version 8 oder höher ausführen, um eine MySQL-Datenbankversion zu exportieren, die älter als Version 8 ist, wird der Fehler Unknown table 'COLUMN_STATISTICS' in information_schema (1109) ausgegeben.
Mögliche Ursache
MySQL-Datenbanken in Versionen vor 8 haben keine COLUMN_STATISTICS-Tabelle. Das Dienstprogramm mysqldump in Version 8 und höher versucht standardmäßig, diese Tabelle zu exportieren. Der Export schlägt fehl, da 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
Für die Quelldatenbank ist möglicherweise die Variable innodb_large_prefix festgelegt. Dadurch können Indexschlüsselpräfixe länger als 767 Byte sein. Der Standardwert für MySQL 5.6 ist OFF.
Lösungsvorschlag
Setzen Sie das Flag innodb_large_prefix beim Erstellen der Zieldatenbank 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 Dumpprozesses keine Tabellen und nehmen Sie keine anderen DDL-Änderungen vor.Sie können mit einem Script 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
Es kann ein Ereignis, eine Ansicht, eine Funktion oder eine Prozedur in der Quelldatenbank mit superuser@localhost (z. B. root@localhost) vorhanden sein. Dies wird von Cloud SQL nicht unterstützt.
Lösungsvorschlag
Informationen dazu finden Sie in diesem Dokument zum Migrieren 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 nicht in der Replikatdatenbank vorhanden ist.
Lösungsvorschlag
Informationen dazu finden Sie in diesem Dokument zum Migrieren 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 dass auf diesen Nutzer in den Objektdefinitionen der Quelldatenbank verwiesen wird.
Lösungsvorschlag
Informationen dazu finden Sie in diesem Dokument zum Migrieren 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.
- Möglicherweise enthält die Quelldatenbank Tabellen mit großen Blobs oder langen Strings, für die
max_allowed_packetauf eine größere Zahl in der Quelldatenbank festgelegt werden muss.
Lösungsvorschlag
- Prüfen Sie, ob die Quelldatenbankinstanz aktiv und erreichbar ist.
- Konfigurieren Sie das Flag
max-allowed-packetim Migrationsjob und starten Sie den Migrationsjob dann neu. Alternativ können Sie mit der Optionmax_allowed_packeteinen manuellen Dump erstellen, um die Daten in eine Dumpdatei auszulesen und mit dieser zu migrieren. - Wenn Sie
max_allowed_packeterhöhen möchten, müssen Sie höchstwahrscheinlich die Einstellungennet_read_timeoutundnet_write_timeoutin 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 in eine Dumpdatei auszulesen und mit dieser zu migrieren.
Es werden keine Daten repliziert
Die erste Datenmigration war erfolgreich, aber es werden keine Daten repliziert.
Mögliche Ursache
Dies kann daran liegen, dass in der Quelldatenbank bestimmte Replikations-Flags definiert sind, die die Replikation von manchen oder allen Datenbankänderungen verhindern.
Lösungsvorschlag
Achten Sie darauf, dass Replikations-Flags wie binlog-do-db, binlog-ignore-db, replicate-do-db und replicate-ignore-db nicht so festgelegt sind, dass sie Konflikte verursachen.
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 funktioniert nach einer Weile nicht mehr.
Die Datenmigration verlief anfangs erfolgreich, danach jedoch nicht mehr.
Mögliche Ursache
Dieses Problem kann viele Ursachen haben.
Lösungsvorschlag
- Prüfen Sie die Replikationsmesswerte für Ihre Zielinstanz in der Cloud Monitoring-Benutzeroberfläche.
- Die Fehler aus dem MySQL-E/A-Thread oder dem SQL-Thread finden Sie in Cloud Logging in den mysql.err-Logdateien.
- Dieser Fehler kann auch auftreten, wenn eine Verbindung zur Zielinstanz hergestellt wird. Führen Sie den Befehl
SHOW REPLICA STATUSaus und suchen Sie in der Ausgabe nach folgenden Feldern:- Replica_IO_Running
- Replica_SQL_Running
- Last_IO_Error
- Last_SQL_Error
Hinweis:
SHOW REPLICA STATUSist ein Alias, der in MySQL 8.0.22 eingeführt wurde. Verwenden Sie für ältere Versionen (MySQL 5.7, MySQL 8.0) den alten Alias des Befehls „status“. Weitere Informationen finden Sie in der MySQL-Dokumentation unter Statusanweisung.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_Errorerhalten, kann das an einer unzureichenden Einstellung für die Binlog-Aufbewahrung auf der Quellinstanz liegen.Wenn Sie den Fehler
error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIESerhalten, kann das daran liegen, dass die Zielinstanz aufgrund eines Verbindungs- oder Authentifizierungsproblems keine Verbindung mehr zur Quelle herstellen kann.
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 Laufwerkgröße der Zielinstanz.
Fehler beim Herstellen einer Verbindung zur Quelldatenbank
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 der Verbindung.
Migration von einer verwalteten Datenbank (Amazon RDS/Aurora) startet nicht
Der Migrationsjob kann nicht gestartet werden.
Mögliche Ursache
Die Migration von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen erfordert zu Beginn der Migration eine kurze Ausfallzeit.
Lösungsvorschlag
- Für Amazon RDS folgen Sie dieser Anleitung.
- Für Amazon Aurora folgen Sie dieser Anleitung.
Binlog ist in der Quelldatenbank falsch konfiguriert
Sie sehen einen Fehler, der auf ein Problem mit den Binärprotokollen hinweist.
Mögliche Ursache
Dies kann bei kontinuierlichen MySQL-Migrationsjobs auftreten, wenn die binlog-Konfiguration in der Quelldatenbank falsch ist.
Lösungsvorschlag
Beachten Sie die Definitionen hier.
Fehler beim Lesen der bereitgestellten Dumpdatei
Sie sehen eine Fehlermeldung, die auf ein Problem mit der Dumpdatei hinweist.
Mögliche Ursache
DMS kann die angegebene Dumpdatei nicht finden.
Lösungsvorschlag
- Prüfen Sie den Dumppfad, um sicherzustellen, dass sich dort eine gültige Datei befindet, oder ändern Sie den Pfad.
- Wenn Sie den Pfad ändern, verwenden Sie eine
PATCH-Anfrage, um sicherzustellen, dass er für den Job verwendet wird. - Starten Sie den Migrationsjob neu.
Die 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 einen längeren Zeitraum pausiert wird, wodurch die Binlog-Position verloren geht. Migrationsjobs sollten nicht für Zeiträume pausiert werden, die an die Aufbewahrungsdauer des Binlogs heranreichen.
Lösungsvorschlag
Starten Sie den Migrationsjob neu.
Fehler beim Ausführen des Migrationsjobs aufgrund inkompatibler Versionen von Quell- und Zieldatenbank
Die Kombination der Quell- und Zieldatenbankversionen wird nicht unterstützt.
Mögliche Ursache
Die angegebene Version der Quelldatenbank ist nicht mit der Version der Zieldatenbank kompatibel.
Lösungsvorschlag
Achten Sie darauf, dass die Version der Zieldatenbank mit der Version der Quelldatenbank identisch ist oder eine Hauptversion darüber liegt. 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 den Migrationsjob angezeigt wurden.
Die Laufwerknutzung der Cloud SQL-Zielninstanz sinkt auf null
Die Laufwerknutzung sinkt während der Migration plötzlich auf null.
Mögliche Ursache
Beim Importieren der vollständigen Dump-Daten kann ein Fehler auftreten. In diesem Fall wird beim Migrationsprozess versucht, die Daten noch einmal zu laden. Dabei werden zuerst die vorhandenen Daten in der Zielinstanz gelöscht (daher sinkt die Laufwerknutzung auf Null). Anschließend wird versucht, die Daten neu zu laden.
Lösungsvorschlag
Rufen Sie den Log-Explorer auf und wählen Sie in der Ressourcenliste die Zielinstanz aus.
Suchen Sie nach einer ähnlichen Protokollmeldung:
DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again."
Suchen Sie nach der Meldung nach dem Text import failed: und versuchen Sie, das zugrunde liegende Problem zu beheben.