Résoudre une erreur
Le processus de migration peut générer des erreurs lors de l'exécution.
- Certaines erreurs, telles qu'un mot de passe incorrect dans la base de données source, peuvent être récupérées, ce qui signifie qu'elles peuvent être corrigées et que le job de migration reprend automatiquement.
- Certaines sont irrécupérables, comme la perte de la position binlog, ce qui signifie que le job de migration doit être redémarré depuis le début.
Lorsqu'une erreur se produit, l'état du job de migration passe à Failed et le sous-état reflète le dernier état avant l'échec.
Pour résoudre un problème, accédez à la tâche de migration ayant échoué pour afficher l'erreur, puis suivez la procédure décrite dans le message d'erreur.
Pour afficher plus de détails sur l'erreur, accédez à Cloud Monitoring à l'aide du lien sur le job de migration. Les journaux sont filtrés en fonction du job de migration spécifique.
Le tableau suivant contient quelques exemples de problèmes et la façon de les résoudre :
| Pour ce problème... | Le problème peut être... | Essayez : |
|---|---|---|
| Les paramètres de la base de données de destination sont différents de la configuration Terraform utilisée pour provisionner la base de données. (Ce problème est parfois appelé dérive de configuration.) | Lorsque vous migrez vers une base de données de destination existante, Database Migration Service modifie certains paramètres de votre base de données de destination pour exécuter le job de migration. | Vous devez réappliquer les paramètres que vous utilisez dans votre configuration Terraform après avoir promu le job de migration. Consultez la section Dérive de la configuration Terraform. |
Message d'erreur : ERROR: Error executing DDL script for view {view_name} MySQL Error {1049 or 1146 or 1824} |
Le vidage initial a échoué, car les bases de données sélectionnées contiennent des objets qui font référence à des données dans des bases de données qui ne sont pas sélectionnées pour la migration. | Examinez le message d'erreur suivant pour identifier l'objet référencé manquant. Si vous souhaitez réessayer la migration, ajoutez d'abord la base de données contenant l'objet au job de migration ou supprimez la base de données contenant la référence. |
| La réplication a échoué avec le code d'erreur 1049, 1146 ou 1824 pendant la phase CDC. | Cela peut se produire si une instruction LDD est exécutée sur :
|
Examinez le message d'erreur suivant pour identifier l'objet référencé manquant. Si vous souhaitez réessayer la migration, ajoutez d'abord la base de données contenant l'objet au job de migration ou supprimez la base de données contenant la référence. |
Message d'erreur : Error processing table {table_name}: MySQL Error 1118
(42000): Row size too large (>8126). |
Les tables qui utilisent des colonnes VARCHAR peuvent comporter des lignes qui dépassent la taille maximale autorisée par InnoDB (le moteur de stockage par défaut utilisé dans MySQL). |
Vous pouvez débloquer votre job de migration en convertissant les colonnes en BLOB ou TEXT, ou en définissant temporairement l'indicateur
innodb_strict_mode sur off.
Consultez Erreur 1118 : taille de ligne trop grande. |
Le job de migration a échoué lors de la phase de vidage complet avec le message d'erreur suivant :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}.
|
Ce problème se produit lors de la migration entre les versions de MySQL.
Il est possible que des entités de votre version MySQL source utilisent des mots qui ne sont pas autorisés dans la version MySQL vers laquelle vous souhaitez migrer.
Par exemple, dans MySQL 5.7, vous pouvez utiliser le mot |
Renommez les objets de base de données source référencés dans le message d'erreur ou placez-les entre guillemets inversés (``) pour échapper à la syntaxe. Une fois l'opération terminée, relancez le job de migration.
|
Message d'erreur : ERROR 1109 (42S02): Unknown table in <schema name here> |
Database Migration Service ne migre pas les schémas système mysql, performance_schema, information_schema, ndbinfo ni sys.
Votre job de migration peut échouer si la base de données source contient des objets qui font référence à des tables de l'un de ces schémas. |
Recherchez dans votre base de données source les objets qui font référence à des tables contenues dans l'un des schémas système non migrés. Consultez ERROR 1109 (42S02) : table inconnue dans <nom du schéma>. |
Message d'erreur : Unknown table 'COLUMN_STATISTICS' in information_schema (1109) |
Pertinent pour les scénarios de vidage manuel de base de données avec mysqldump uniquement.Les bases de données MySQL dont la version est antérieure à 8 ne disposent pas de la table COLUMN_STATISTICS. L'utilitaire |
Utilisez l'option --column-statistics=0 lorsque vous utilisez mysqldump. |
Message d'erreur : Specified key was too long; max key length is 767 bytes. |
La variable innodb_large_prefix peut être définie sur l'instance de base de données source. |
Définissez l'option innodb_large_prefix sur ON lors de la création de l'instance de destination ou mettez à jour l'instance de destination existante avec l'option. |
Message d'erreur : Table definition has changed. |
Des modifications LDD (langage de définition de données) ont été appliquées pendant le processus de vidage. | Évitez les modifications du LDD pendant le processus de vidage. |
Message d'erreur : Access denied; you need (at least one of) the SUPER privilege(s) for this operation. |
Il est possible qu'un événement, une vue, une fonction ou une procédure de la base de données source utilise un super-utilisateur@localhost (tel que root@localhost). Cette méthode n'est pas compatible avec Cloud SQL. | En savoir plus sur l'utilisation de DEFINER dans Cloud SQL |
Message d'erreur : Definer user 'x' does not exist. Please create the user on the replica.
|
L'utilisateur n'existe pas sur la réplique. | En savoir plus sur l'utilisation de DEFINER dans Cloud SQL |
Message d'erreur : ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost. |
La base de données source contient une clause DEFINER qui n'existe pas dans l'instance dupliquée. |
En savoir plus sur l'utilisation de DEFINER dans Cloud SQL |
Message d'erreur : Lost connection to MySQL server during query when dumping table. |
Peut-être que la base de données source est devenue inaccessible ou que le vidage contenait des paquets trop volumineux. | Essayez ces suggestions. |
Message d'erreur : Got packet bigger than 'max_allowed_packet' bytes when dumping table. |
La taille du paquet est supérieure à celle autorisée par les paramètres. | Utilisez la vidange manuelle avec l'option max_allowed_packet. |
| La migration initiale des données a abouti, mais aucune donnée n'est répliquée. | Des options de réplication peuvent être en conflit. | Vérifiez la paramétrage de ces options. |
| La migration initiale des données a abouti, mais la réplication des données a cessé de fonctionner après un certain temps. | Il peut y avoir de nombreuses causes. | Nous vous suggérons d'essayer ces solutions. |
Message d'erreur : mysqld check failed: data disk is full. |
Le disque de données de l'instance de destination est saturé. | Augmentez la taille du disque de l'instance de destination. Vous pouvez augmenter manuellement la taille du disque ou activer l'augmentation automatique de l'espace de stockage. |
| Échec de la connexion à l'instance de base de données source. | Un problème de connectivité est survenu entre l'instance de base de données source et l'instance de destination. | Suivez les étapes décrites dans l'article Déboguer la connectivité. |
| La migration depuis une base de données gérée (Amazon RDS/Aurora) ne démarre pas. | La migration depuis une base de données source gérée sans privilèges SUPERUSER nécessite une brève interruption au début de la migration. | Suivez la procédure décrite dans cet article. |
| Le binlog n'est pas configuré correctement dans la base de données source. | Les définitions Binlog sont incorrectes. | Pour les jobs de migration MySQL continus, assurez-vous de respecter les définitions de binlog requises. |
| Échec de la recherche du fichier de dump. | DMS ne parvient pas à trouver le fichier de dump fourni. | Cela peut se produire si le job de migration ne trouve pas le fichier de dump à l'emplacement indiqué.
|
| Impossible de reprendre la réplication, car la position du binlog a été perdue. | La position binlog a été perdue et la tâche de migration n'a pas pu être reprise. | Cette erreur peut se produire lorsque le processus de réplication est suspendu pendant une longue période, ce qui entraîne la perte de la position du binlog. Les jobs de migration ne doivent pas être mis en veille pendant des périodes proches de la période de conservation des journaux binlog. Redémarrez le job de migration. |
Lorsque vous migrez vers une
instance de destination existante, le message d'erreur suivant s'affiche :
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.
|
Votre instance Cloud SQL de destination contient des données supplémentaires. Vous ne pouvez migrer que vers des instances existantes et vides. Consultez les limitations connues. | Promouvez votre instance de destination pour en faire une instance en lecture/écriture, supprimez les données supplémentaires et relancez le job de migration. Consultez Effacer les données supplémentaires de votre instance de destination existante. |
| Échec de l'exécution du job de migration en raison de versions de base de données source et de destination incompatibles. | La version de la base de données source fournie n'est pas compatible avec la version de la base de données de destination. | Assurez-vous que la version de la base de données de destination est identique ou une version majeure supérieure à celle de la base de données source, puis créez un job de migration. |
Message d'erreur : Unable to connect to source database server.
|
Database Migration Service ne peut pas établir de connexion au serveur de base de données source. | Assurez-vous que les instances de base de données source et de destination peuvent communiquer entre elles, et que vous avez rempli toutes les conditions préalables requises qui s'affichent lorsque vous définissez les paramètres de la tâche de migration. |
Message d'erreur : Timeout waiting for no write traffic on source.
|
La migration depuis une base de données source gérée sans privilèges SUPERUSER entraîne un bref temps d'arrêt au début de la migration. |
Suivez la procédure décrite dans Migrer à partir de RDS MySQL sans privilèges SUPERUSER. |
Message d'erreur : ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.
|
Il peut y avoir une incohérence entre la valeur du flag lower_case_table_names pour la base de données source et la valeur du flag pour l'instance Cloud SQL de destination. |
Définissez la valeur de l'option pour l'instance Cloud SQL afin qu'elle corresponde à la valeur de l'option pour la base de données source. |
Message d'erreur : ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}.
|
Certains objets de la base de données source, tels que les vues, les fonctions, les procédures stockées ou les déclencheurs, font référence à une table qui n'existe plus dans la base de données. | Vérifiez si ces objets existent. Si tel est le cas, supprimez les objets de la base de données source ou ajoutez-y la table à laquelle les objets font référence. |
Message d'erreur : 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. |
Vous avez fourni un mot de passe incorrect pour l'instance source. Ou bien l'instance source force une connexion SSL, mais le job de migration n'est pas configuré pour utiliser les certifications SSL. | Vérifiez que le nom d'utilisateur, le mot de passe et les paramètres SSL de l'instance source sont corrects en utilisant le client Si l'instance source est Cloud SQL, consultez Exiger SSL/TLS pour vérifier si SSL/TLS est requis pour les connexions TCP. |
| Le délai de réplication est systématiquement long. | La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de réplication se produit lorsque le thread Cloud SQL pour MySQL d'une réplique ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de réplication :
|
Voici quelques solutions possibles :
|
Message d'erreur : 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. |
Il est possible que la base de données source utilise des jeux de caractères ou des classements non compatibles avec l'instance répliquée Cloud SQL sélectionnée. Par exemple, AWS Aurora version 2.x est compatible avec MySQL 5.7. Toutefois, cette version est compatible avec le classement utf8mb4_0900_as_ci, qui n'est pas compatible avec Cloud SQL pour MySQL 5.7. |
|
Erreur 1108 : taille de la ligne trop grande
Les tables dont les colonnes stockent des chaînes de longueur variable peuvent comporter des lignes qui dépassent la taille maximale par défaut des lignes InnoDB.Solutions possibles
Ajuster le schéma de la table source
Ce problème peut se reproduire chaque fois que vous exécutez des instructions INSERT dans les tables qui dépassent la limite de taille maximale des lignes. Pour éviter d'autres problèmes, il est préférable d'ajuster vos tableaux avant de réessayer la migration :
- Remplacez votre table
ROW_FORMATparDYNAMICouCOMPRESSEDen exécutant la requête suivante :ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
- TABLE_NAME est le nom de la table dont les lignes dépassent la taille maximale autorisée.
- FORMAT_NAME est
DYNAMICouCOMPRESSED
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- Convertissez les données de ligne en BLOB ou TEXT. Pour ce faire, vous pouvez utiliser la
fonction
CONVERT().
Désactiver le mode strict InnoDB
Si vous ne pouvez pas ajuster le schéma de la table source, vous pouvez désactiver temporairement la validation InnoDB pour terminer le job de migration. N'oubliez pas que le problème peut se reproduire lors de futures tentatives d'écriture dans la base de données. Il est donc préférable d'ajuster le schéma de votre table lorsque cela est possible.
Pour désactiver temporairement la validation InnoDB afin de terminer votre tâche de migration, procédez comme suit :
| Si… | Ensuite… |
|---|---|
| Si vous migrez vers une nouvelle instance de destination |
|
| Si vous migrez vers une instance de destination existante |
|
Effacer les données supplémentaires de votre instance de destination existante
Lorsque vous migrez vers une
instance de destination existante, le message d'erreur suivant s'affiche :
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.
Ce problème peut se produire si votre instance de destination contient des données supplémentaires. Vous ne pouvez migrer que vers des instances existantes et vides. Consultez les limitations connues.
Solutions possibles
Effacez les données supplémentaires de votre instance de destination et redémarrez le job de migration en procédant comme suit :
- Arrêtez la tâche de migration.
- À ce stade, votre instance Cloud SQL de destination est en mode
read-only. Promouvez l'instance de destination pour obtenir un accès en écriture. - Connectez-vous à votre instance Cloud SQL de destination.
- Supprimez les données supplémentaires des bases de données de votre instance de destination. Votre destination ne peut contenir que des données de configuration système. Les bases de données de destination ne peuvent pas contenir de données utilisateur (telles que des tables). Vous pouvez exécuter différentes instructions SQL sur vos bases de données pour trouver des données non système. Par exemple :
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- Démarrez le job de migration.
Dérive de configuration Terraform
Lorsque vous migrez vers une base de données de destination existante, Database Migration Service modifie certains paramètres de votre base de données de destination pour exécuter le job de migration. Pour les bases de données provisionnées avec Terraform, cette interaction peut entraîner une dérive de configuration, où la configuration réelle de la base de données de destination est différente de celle définie dans vos fichiers Terraform.Solutions possibles
N'essayez pas de réappliquer la configuration Terraform lorsque le job de migration est en cours d'exécution. Vous pouvez ajuster la configuration nécessaire en toute sécurité une fois votre base de données de destination promue. Database Migration Service apporte les modifications suivantes à votre instance Cloud SQL de destination :- La configuration de la sauvegarde est définie sur les valeurs par défaut.
- La récupération à un moment précis est réinitialisée sur les valeurs par défaut.
ERROR 1109 (42S02) : table inconnue dans <nom du schéma>
Les jobs de migration échouent et affichent le message suivant : ERROR 1109 (42S02): Unknown table in <schema name here>
, par exemple : ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema.
Cause possible
Database Migration Service ne migre pas les schémas système mysql, performance_schema, information_schema, ndbinfo ni sys (voir
Limites connues).
Votre tâche de migration peut échouer si la base de données source contient des objets qui font référence à des tables de l'un de ces schémas.
Solutions possibles
Recherchez dans votre base de données source les objets qui font référence aux tables des schémas système. Dans votre base de données source, exécutez les requêtes suivantes :# 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'
Table "COLUMN_STATISTICS" inconnue dans information_schema
Lorsque vous exécutez l'utilitaire mysqldump version 8 ou ultérieure pour exporter une base de données MySQL antérieure à la version 8, l'erreur suivante s'affiche : Unknown table 'COLUMN_STATISTICS' in information_schema (1109).
Cause possible
Les bases de données MySQL dont la version est antérieure à 8 ne disposent pas de la table COLUMN_STATISTICS. L'utilitaire mysqldump des versions 8 et ultérieures tente d'exporter ce tableau par défaut. L'exportation échoue, car la colonne n'existe pas.
Solutions possibles
Ajoutez l'indicateur --column-statistics=0 à votre commande mysqldump pour supprimer la table COLUMN_STATISTICS de l'exportation. Pour en savoir plus, consultez Exporter une base de données MySQL à l'aide de mysqldump.
La clé spécifiée est trop longue. La longueur maximale de la clé est de 767 octets
L'erreur Specified key was too long; max key length is 767 bytes. s'affiche.
Cause possible
La variable innodb_large_prefix peut être définie dans la base de données source. Cela autorise les préfixes de clé d'index de plus de 767 octets. La valeur par défaut est OFF pour MySQL 5.6.
Solutions possibles
Définissez l'option innodb_large_prefix sur ON lors de la création de la base de données de destination ou mettez à jour la base de données de destination existante avec l'option.
La définition de la table a changé
L'erreur Table definition has changed s'affiche.
Cause possible
Des modifications LDD ont été appliquées pendant le processus de vidage.
Solutions possibles
Ne modifiez pas les tables et n'effectuez aucune autre modification LDD pendant le processus de vidage.Vous pouvez utiliser un script pour vérifier que les opérations LDD sont arrêtées.
Accès refusé. Vous avez besoin d'au moins un des privilèges SUPER pour cette opération
L'erreur Access denied; you need (at least one of) the SUPER privilege(s) for this operation s'affiche.
Cause possible
Il est possible qu'un événement, une vue, une fonction ou une procédure de la base de données source utilise un super-utilisateur@localhost (tel que root@localhost). Cette méthode n'est pas compatible avec Cloud SQL.
Solutions possibles
Reportez-vous à ce document pour savoir comment migrer une base de données avec des clauses DEFINER.
Message d'erreur : Definer user 'x' does not exist. Please create the user on the replica.
L'erreur Definer user 'x' does not exist. Please create the user on the replica. s'affiche.
Cause possible
L'origine du problème est qu'un utilisateur de la base de données source avec la clause DEFINER n'existe pas dans la base de données dupliquée.
Solutions possibles
Reportez-vous à ce document pour savoir comment migrer une base de données avec des clauses DEFINER. Vous devrez peut-être créer l'utilisateur dans la base de données répliquée.
Message d'erreur : ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost
L'erreur ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost s'affiche.
Cause possible
L'origine du problème est qu'un utilisateur de la base de données source avec la clause DEFINER n'existe pas dans la base de données dupliquée, alors qu'il est également référencé dans les définitions d'objets de la base de données source.
Solutions possibles
Reportez-vous à ce document pour savoir comment migrer une base de données avec des clauses DEFINER. Vous devrez peut-être créer un ou plusieurs utilisateurs dans la base de données répliquée.
Connexion au serveur MySQL interrompue pendant la requête lors du vidage de la table
L'erreur Lost connection to MySQL server during query when dumping table s'affiche.
Cause possible
- Il est possible que l'instance de base de données source soit devenue inaccessible depuis l'instance de destination.
- La base de données source peut contenir des tables avec des blobs volumineux ou des chaînes longues qui nécessitent de définir
max_allowed_packetsur un plus grand nombre dans la base de données source.
Solutions possibles
- Vérifiez que l'instance de base de données source est opérationnelle et accessible.
- Configurez l'indicateur
max-allowed-packetdans le job de migration, puis redémarrez-le. Vous pouvez également générer un vidage manuel avec l'optionmax_allowed_packetpour vider les données et effectuer la migration avec le fichier de dump. - Pour augmenter
max_allowed_packet, vous devrez probablement ajuster les paramètresnet_read_timeoutetnet_write_timeoutde la base de données source (en général, vous devez les augmenter jusqu'à ce que l'erreur de connexion cesse de se produire).
Le nombre d'octets du paquet est supérieur à "max_allowed_packet" lors du vidage de la table
L'erreur Got packet bigger than 'max_allowed_packet' bytes when dumping table s'affiche.
Cause possible
La taille du paquet est supérieure à celle autorisée par les paramètres.
Solutions possibles
Créez un job de migration à l'aide d'un vidage manuel avec l'option max_allowed_packet pour vider les données et effectuer la migration avec le fichier de dump.
Aucune donnée n'est répliquée
La migration initiale des données a abouti, mais aucune donnée n'est répliquée.
Cause possible
Il se peut que votre base de données source ait défini des options de réplication qui empêchent la réplication de certaines ou de toutes les modifications de la base de données.
Solutions possibles
Assurez-vous que les options de réplication telles que binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db ne sont pas définies de manière conflictuelle.
Exécutez la commande show master status sur la base de données source pour afficher les paramètres actuels.
La migration initiale des données a abouti, mais la réplication des données a cessé de fonctionner après un certain temps
La migration initiale des données a abouti, mais la réplication des données a cessé de fonctionner après un certain temps.
Cause possible
Il peut y avoir de nombreuses causes à ce problème.
Solutions possibles
- Vérifiez les métriques de réplication de votre instance de destination dans Cloud Monitoring.
- Les erreurs du thread d'E/S MySQL ou du thread SQL sont disponibles dans Cloud Logging, dans les fichiers journaux
mysql.err. - Cette erreur peut également se produire lors de la connexion à l'instance de destination. Exécutez la commande
SHOW REPLICA STATUSet vérifiez les champs suivants dans le résultat :- Replica_IO_Running
- Replica_SQL_Running
- Last_IO_Error
- Last_SQL_Error
Remarque :
SHOW REPLICA STATUSest un alias introduit dans MySQL 8.0.22. Pour les versions précédentes (MySQL 5.7, MySQL 8.0), utilisez l'ancien alias de la commande d'état. Pour en savoir plus, consultez la section Instruction d'état dans la documentation MySQL.Si vous avez reçu l'erreur
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, cela peut être dû à un paramètre de conservation du binlog insuffisant sur l'instance source.Si vous avez reçu l'erreur
error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES, cela peut être dû au fait que l'instance de destination n'a pas réussi à se reconnecter à la source en raison d'un problème de connectivité ou d'authentification.
Échec de la vérification mysqld : le disque de données est saturé
L'erreur mysqld check failed: data disk is full s'affiche.
Cause possible
Le disque de données de l'instance de destination est probablement saturé.
Solutions possibles
Augmentez la taille du disque de l'instance de destination.
Échec de la connexion à la base de données source
Échec de la connexion à la base de données source.
Cause possible
Un problème de connectivité est survenu entre l'instance de base de données source et l'instance de destination.
Solutions possibles
Suivez la procédure décrite dans l'article sur le débogage de la connectivité.
La migration depuis une base de données gérée (Amazon RDS/Aurora) ne démarre pas
La tâche de migration ne démarre pas.
Cause possible
La migration depuis une base de données source gérée sans privilèges SUPERUSER nécessite une brève interruption au début de la migration.
Solutions possibles
- Pour Amazon RDS, suivez les étapes décrites dans cet article.
- Pour Amazon Aurora, suivez la procédure décrite dans cet article.
Le binlog n'est pas configuré correctement dans la base de données source.
Une erreur s'affiche, indiquant un problème avec les journaux binaires.
Cause possible
Cela peut se produire pour les jobs de migration MySQL continus si la configuration du binlog est incorrecte dans la base de données source.
Solutions possibles
Veillez à respecter les définitions ici.
Échec de la lecture du fichier de dump fourni
Une erreur indiquant un problème lié au fichier de dump s'affiche.
Cause possible
DMS ne parvient pas à trouver le fichier de dump fourni.
Solutions possibles
- Vérifiez le chemin d'accès au fichier de vidage pour vous assurer qu'un fichier approprié s'y trouve, ou modifiez le chemin d'accès.
- Si vous modifiez le chemin d'accès, utilisez une requête
PATCHpour vous assurer que le job l'utilise. - Redémarrez le job de migration.
Impossible de reprendre la réplication, car la position du binlog a été perdue
La position du binlog est perdue.
Cause possible
Cette erreur peut se produire lorsque le processus de réplication est suspendu pendant une longue période, ce qui entraîne la perte de la position du binlog. Les jobs de migration ne doivent pas être mis en veille pendant des périodes proches de la durée de conservation des journaux binaires.
Solutions possibles
Redémarrez le job de migration.
Échec de l'exécution du job de migration en raison de versions de base de données source et de destination incompatibles
Les versions de base de données source et de destination ne sont pas compatibles.
Cause possible
La version de la base de données source fournie n'est pas compatible avec la version de la base de données de destination.
Solutions possibles
Assurez-vous que la version de la base de données de destination est identique à la version de la base de données source ou supérieure d'une version majeure, puis créez un job de migration.
Impossible de se connecter au serveur de base de données source
L'erreur Unable to connect to source database server s'affiche.
Cause possible
Database Migration Service ne peut pas établir de connexion au serveur de base de données source.
Solutions possibles
Vérifiez que les instances de base de données source et de destination peuvent communiquer entre elles. Ensuite, assurez-vous d'avoir rempli toutes les conditions préalables requises qui s'affichaient lorsque vous définissiez les paramètres de votre job de migration.
L'utilisation du disque de l'instance Cloud SQL de destination tombe à zéro
L'utilisation du disque tombe soudainement à zéro pendant la migration.
Cause possible
Il est possible qu'une erreur se produise lors de l'importation des données de vidage complet. Dans ce cas, le processus de migration tente de charger à nouveau les données. Ce processus efface d'abord les données existantes sur l'instance de destination (c'est pourquoi l'utilisation du disque diminue jusqu'à zéro), puis tente de recharger les données.
Solutions possibles
Accédez à l'explorateur de journaux, puis sélectionnez votre instance de destination dans la liste des ressources.
Recherchez un message de journal semblable à celui-ci :
DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again."
Recherchez le message après le texte import failed: et essayez de résoudre le problème sous-jacent.