Fehlerbehebung
Im Migrationsjobprozess können während der Laufzeit Fehler auftreten.
- Einige Fehler, wie z. B. ein ungültiges Passwort in der Quelldatenbank, sind wiederherstellbar. Dies bedeutet, dass diese Fehler behoben werden können und der Migrationsjob anschließend automatisch fortgesetzt wird.
- Einige sind nicht wiederherstellbar, z. B. eine verlorene 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 gibt den letzten Status vor dem Fehler an.
Zum Beheben eines Fehlers rufen Sie den fehlgeschlagenen Migrationsjob auf, um den Fehler anzuzeigen, und folgen dann den Schritten 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 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 Hochstufen des Migrationsjobs noch einmal anwenden. Weitere Informationen finden Sie unter Abweichung der Terraform-Konfiguration. |
Fehlermeldung: ERROR: Error executing DDL script for view {view_name} MySQL Error {1049 or 1146 or 1824} |
Der erste Dump ist fehlgeschlagen, weil die ausgewählten Datenbanken Objekte enthalten, die auf Daten in Datenbanken verweisen, die nicht für die Migration ausgewählt wurden. | Sehen Sie sich die nachfolgende Fehlermeldung an, um das fehlende referenzierte Objekt zu ermitteln. Wenn Sie die Migration noch einmal versuchen möchten, fügen Sie dem Migrationsjob zuerst die Datenbank hinzu, die das Objekt enthält, oder entfernen Sie die Datenbank, die die Referenz enthält. |
| Die Replikation ist während der CDC-Phase mit dem Fehlercode 1049, 1146 oder 1824 fehlgeschlagen. | Das kann passieren, wenn eine DDL-Anweisung für Folgendes ausgeführt wird:
|
Sehen Sie sich die nachfolgende Fehlermeldung an, um das fehlende referenzierte Objekt zu ermitteln. Wenn Sie die Migration noch einmal versuchen möchten, fügen Sie dem Migrationsjob zuerst die Datenbank hinzu, die das Objekt enthält, oder entfernen Sie die Datenbank, die die Referenz enthält. |
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 Standardspeicher-Engine) zulässige maximale Größe überschreiten. |
Sie können die Migration Ihres Jobs entsperren, 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 des vollständigen Dumps 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 |
Benennen Sie die in der Fehlermeldung genannten Quelldatenbankobjekte um oder setzen Sie sie in Graviszeichen (``), um die Syntax zu maskieren. Wiederholen Sie den Migrationsjob, wenn die Einrichtung abgeschlossen ist.
|
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 nicht migrierten Systemschemas verweisen. 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 Datenbankdumps mit mysqldump.MySQL-Datenbanken in Versionen vor 8 haben die Tabelle COLUMN_STATISTICS nicht. Das |
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 (wie 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 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, den es im Replikat nicht gibt. |
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. | Verwenden Sie „mysqldump“ 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. | Bei der 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, dass Sie die erforderlichen binlog-Definitionen einhalten. |
| Die Dumpdatei wurde nicht gefunden. | DMS kann die angegebene Dump-Datei nicht finden. | Dies kann passieren, wenn die Dump-Datei am angegebenen Speicherort nicht gefunden wird.
|
| Die Replikation kann nicht fortgesetzt werden, wenn die Binlog-Position verloren geht. | Die Binlog-Position ist verloren gegangen und der Migrationsjob konnte nicht fortgesetzt werden. | Dieser Fehler kann auftreten, wenn der Replikationsprozess für längere Zeit pausiert wird, wodurch die Binlog-Position verloren geht. Migrationsjobs sollten nicht für einen Zeitraum angehalten werden, der sich dem Aufbewahrungszeitraum für Binlog-Dateien nähert. 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. Bekannte Einschränkungen | Stufen Sie die Zielinstanz hoch, damit sie zu einer Lese-/Schreibinstanz wird, 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. |
| Fehler beim Ausführen des Migrationsjobs aufgrund inkompatibler Versionen von Quell- und Zieldatenbank. | Die angegebene Quelldatenbankversion ist nicht mit der Zieldatenbankversion kompatibel. | Achten Sie darauf, dass die Zieldatenbankversion mit der Quelldatenbankversion übereinstimmt oder eine Hauptversion höher ist, und 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 Zielinstanzen der Datenbank miteinander kommunizieren können und ob Sie alle erforderlichen Voraussetzungen erfüllt haben, die beim Festlegen der Einstellungen für den Migrationsjob angezeigt wurden. |
Fehlermeldung: Timeout waiting for no write traffic on source.
|
Wenn Sie von einer verwalteten Quelldatenbank ohne SUPERUSER-Berechtigungen migrieren, kommt es zu Beginn der Migration zu einer kurzen Ausfallzeit. |
Folgen Sie der Anleitung unter RDS MySQL ohne SUPERUSER-Berechtigungen migrieren. |
Fehlermeldung: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.
|
Möglicherweise besteht eine Inkonsistenz zwischen dem Wert des Flags lower_case_table_names für die Quelldatenbank und dem Wert des Flags für die Ziel-Cloud SQL-Instanz. |
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. Wenn dies der Fall ist, entfernen Sie die Objekte entweder aus der Quelldatenbank oder fügen Sie die Tabelle, auf die sich die Objekte beziehen, 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 Wenn die Quellinstanz Cloud SQL ist, lesen Sie den Abschnitt 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. Die 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. |
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. |
|
Fehler 1108: Zeilengröße zu groß
Tabellen mit Spalten, in denen Strings mit variabler Länge gespeichert werden, können Zeilen enthalten, die die standardmäßige maximale InnoDB-Zeilengröße überschreiten.Lösungsvorschlag
Quelltabellenschema anpassen
Dieses Problem kann immer 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 das maximale Zeilenlimit überschreiten.
- FORMAT_NAME ist
DYNAMICoderCOMPRESSED
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- Zeilendaten in BLOB oder TEXT konvertieren Eine Möglichkeit, dies zu erreichen, ist die Verwendung der
Funktion
CONVERT().
Strengen 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. Passen Sie daher das Tabellenschema an, wenn möglich.
So deaktivieren Sie die InnoDB-Validierung vorübergehend, um den Migrationsjob abzuschließen:
| Wenn... | Dann… |
|---|---|
| Wenn Sie zu einer neuen Zielinstanz migrieren |
|
| Wenn Sie zu einer vorhandenen Zielinstanz migrieren |
|
Zusätzliche Daten aus Ihrer vorhandenen Zielinstanz löschen
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.
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:
- Migrationsjob stoppen
- An diesem Punkt befindet sich Ihre Cloud SQL-Zielinstanz 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. Ihr 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-Systemdaten zu finden, z. B.:
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- Migrationsjob starten
Konfigurationsabweichung 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 werden, 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, während der Migrationsjob ausgeführt wird. Sie können die erforderliche Konfiguration nach der Hochstufung der Zieldatenbank problemlos anpassen. Database Migration Service nimmt die folgenden Änderungen an Ihrer Cloud SQL-Zielinstanz vor:- Die Sicherungskonfiguration ist auf Standardwerte festgelegt.
- 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
Mit Database Migration Service werden die Systemschemata mysql, performance_schema, information_schema, ndbinfo oder sys nicht migriert (siehe
Bekannte Einschränkungen).
Ihr 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 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'
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, wird der folgende Fehler angezeigt: 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-Dienstprogramm 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 Ihrem mysqldump-Befehl 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
Möglicherweise ist in der Quelldatenbank 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 ein Skript verwenden, um zu 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 (wie 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 Klausel DEFINER 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 Klausel DEFINER 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 nicht mehr von der Zielinstanz aus 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üssen Sie höchstwahrscheinlich die Einstellungennet_read_timeoutundnet_write_timeoutin der Quelldatenbank anpassen. Im Allgemeinen sollten Sie sie erhöhen, 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 Cloud Monitoring.
- 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 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_Errorerhalten 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: RETRIESerhalten 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 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 Verbindungsproblemen.
Die 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
- Folgen Sie für Amazon RDS der Anleitung in diesem Artikel.
- Für Amazon Aurora folgen Sie der Anleitung in diesem Artikel.
Binlog ist in der Quelldatenbank falsch konfiguriert
Sie sehen eine Fehlermeldung, die auf ein Problem mit den Binärlogs hinweist.
Mögliche Ursache
Dies kann bei kontinuierlichen MySQL-Migrationsjobs auftreten, wenn die binlog-Konfiguration in der Quelldatenbank falsch ist.
Lösungsvorschlag
Halten Sie sich an die Definitionen.
Fehler beim Lesen der bereitgestellten Dumpdatei
Sie sehen eine Fehlermeldung, die auf ein Problem mit der Dump-Datei hinweist.
Mögliche Ursache
DMS kann die angegebene Dump-Datei nicht finden.
Lösungsvorschlag
- Prüfen Sie den Dump-Pfad, um sicherzustellen, dass dort eine geeignete Datei vorhanden ist, oder ändern Sie den Pfad.
- Wenn Sie den Pfad ändern, verwenden Sie eine
PATCH-Anfrage, damit der Job ihn verwendet. - 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 längere Zeit pausiert wird, wodurch die Binlog-Position verloren geht. Migrationsjobs sollten nicht für Zeiträume angehalten werden, die sich der Aufbewahrungsdauer für Binärlogs nähern.
Lösungsvorschlag
Starten Sie den Migrationsjob neu.
Fehler beim Ausführen des Migrationsjobs aufgrund inkompatibler Versionen von Quell- und Zieldatenbank
Die Datenbankversionen der Quelle und des Ziels 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 mit der Quelldatenbankversion übereinstimmt oder eine Hauptversion höher 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.
Die Festplattennutzung der Cloud SQL-Zielinstanz sinkt auf null
Die Festplattennutzung 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 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 Logmeldung:
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.