Résoudre une erreur
Le processus de tâche de migration peut entraîner des erreurs pendant 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 la tâche de migration reprend automatiquement.
- Certaines sont irrécupérables, comme une perte de position binlog, ce qui signifie que la tâche de migration doit être redémarrée depuis le début.
Lorsqu'une erreur se produit, l'état de la tâche de migration passe à Failed, et le sous-état reflète le dernier état avant l'échec.
Pour résoudre une erreur, accédez à la tâche de migration ayant échoué pour afficher l'erreur et suivez la procédure décrite dans le message d'erreur.
Pour en savoir plus sur l'erreur, accédez à Cloud Monitoring à l'aide du lien figurant sur la tâche de migration. Les journaux sont filtrés en fonction de la tâche de migration spécifique.
Le tableau suivant contient quelques exemples de problèmes et la manière de les résoudre:
| Pour ce problème... | Le problème peut être... | Essayez ce qui suit... |
|---|---|---|
| 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 la tâche 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 Divergence de configuration Terraform. |
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 avoir 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 tâche de migration en convertissant des colonnes en BLOB ou en TEXT, ou en définissant temporairement l'indicateur
innodb_strict_mode sur off.
Consultez Erreur 1118: taille de ligne trop importante. |
La tâche 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.
Les entités de votre version MySQL source peuvent utiliser des mots non 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 sources référencés dans le message d'erreur ou placez-les entre guillemets (``) pour échapper à la syntaxe. Une fois la tâche terminée, relancez la tâche 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 ou sys.
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. |
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 qui n'ont pas été migrés. Consultez ERROR 1109 (42S02): table inconnue dans <nom de schéma ici>. |
Message d'erreur : Unknown table 'COLUMN_STATISTICS' in information_schema (1109) |
Applicable aux scénarios de vidage manuel de base de données avec mysqldump uniquement.Les bases de données MySQL antérieures à la version 8 ne contiennent pas 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 le réplica. | 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. |
La base de données source est peut-être devenue inaccessible ou le vidage contenait des paquets trop volumineux. | Suivez 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 un vidage manuel 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é s'est produit entre l'instance de base de données source et l'instance de destination. | Suivez la procédure décrite dans l'article Déboguer la connectivité. |
| La migration à partir d'une base de données gérée (Amazon RDS/Aurora) ne démarre pas. | La migration à partir d'une base de données source gérée sans droits SUPERUSER nécessite un bref temps d'arrêt 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 du journal binaire sont incorrectes. | Pour les jobs de migration MySQL continus, veillez à respecter les définitions de binlog requises. |
| Impossible de trouver le fichier de dump. | DMS ne parvient pas à trouver le fichier de dump fourni. | Cela peut se produire si la tâche de migration ne parvient pas à trouver le fichier de dump à l'emplacement indiqué.
|
| Impossible de reprendre la réplication, car la position du binlog a été perdue. | La position du 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 qui approchent la période de conservation du journal binaire. Redémarrez la tâche de migration. |
Lorsque vous effectuez une migration 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 vides. Consultez la section Limites connues. | Promuvez votre instance de destination pour en faire une instance en lecture/écriture, supprimez les données supplémentaires, puis réessayez la tâche de migration. Consultez la section Supprimer les données supplémentaires de votre instance de destination existante. |
| Échec de l'exécution de la tâche 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 supérieure d'une version majeure à la version de destination source, puis créez une tâche de migration. |
Message d'erreur: Unable to connect to source database server.
|
Database Migration Service ne parvient pas à établir de connexion avec le 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 vos paramètres pour la tâche de migration. |
Message d'erreur: Timeout waiting for no write traffic on source.
|
Migrer à partir d'une base de données source gérée sans autorisations 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 droits SUPER-UTILISATEUR. |
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 de l'option lower_case_table_names pour la base de données source et la valeur de l'option pour l'instance Cloud SQL de destination. |
Définissez la valeur de l'indicateur pour l'instance Cloud SQL afin qu'elle corresponde à celle de l'indicateur 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 la table à laquelle ils font référence à la base de données source. |
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. |
Le mot de passe que vous avez fourni pour l'instance source est incorrect. Ou l'instance source force une connexion SSL, mais la tâche de migration n'est pas configurée pour utiliser des certifications SSL. | Vérifiez que le nom d'utilisateur, le mot de passe et les paramètres SSL sont corrects pour l'instance source en utilisant le client Si l'instance source est Cloud SQL, consultez Exiger SSL/TLS pour vérifier si SSL/TLS est obligatoire 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 s'allonge lorsque le thread Cloud SQL pour MySQL d'une instance dupliquée 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. |
La base de données source peut utiliser des jeux de caractères ou des collations non compatibles avec l'instance répliquée Cloud SQL sélectionnée. Par exemple, AWS Aurora version 2.x, qui est compatible avec MySQL 5.7. Toutefois, cette version est compatible avec la collation utf8mb4_0900_as_ci, qui n'est pas compatible avec Cloud SQL pour MySQL 5.7. |
|
Erreur 1108: taille de ligne trop importante
Les tables dont les colonnes stockent des chaînes de longueur variable peuvent comporter des lignes qui dépassent la taille de ligne maximale InnoDB par défaut.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 les problèmes à l'avenir, il est préférable d'ajuster vos tables 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 limite de taille maximale des lignes
- FORMAT_NAME est
DYNAMICouCOMPRESSED.
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- Convertissez les données de ligne en BLOB ou en TEXT. Pour effectuer cette opération, 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 effectuer la tâche 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 |
|
Supprimer les données supplémentaires de votre instance de destination existante
Lorsque vous effectuez une migration 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 vides. Consultez la section Limitations connues.
Solutions possibles
Supprimez les données supplémentaires de votre instance de destination et redémarrez la tâche 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. Promouvoir l'instance de destination pour obtenir un accès en écriture. - Connectez-vous à l'instance Cloud SQL de destination.
- Supprimez les données supplémentaires des bases de données de vos instances 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 rechercher 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 la tâche de migration.
Écart 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 la tâche 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 la tâche de migration est en cours d'exécution. Vous pouvez ajuster la configuration nécessaire en toute sécurité une fois que votre base de données de destination a été promue. Database Migration Service effectue les modifications suivantes sur votre instance Cloud SQL de destination :- La configuration de sauvegarde est définie sur les valeurs par défaut.
- La restauration à un moment précis est réinitialisée sur les valeurs par défaut.
ERROR 1109 (42S02): table inconnue dans <nom de schéma ici>
Les jobs de migration échouent avec 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 ou sys (voir la section
Limites connues).
Votre tâche de migration peut échouer si la base de données source contient des objets qui référencent 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 à des 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 version de 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 antérieures à la version 8 ne contiennent pas la table COLUMN_STATISTICS. L'utilitaire mysqldump des versions 8 et ultérieures tente d'exporter cette table 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
Consultez 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
Consultez 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 dupliqué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
Consultez 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 dupliqué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 ne soit plus accessible 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 la base de données source est opérationnelle et accessible.
- Configurez l'indicateur
max-allowed-packetdans la tâche de migration, puis redémarrez-la. 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 modifier les paramètresnet_read_timeoutetnet_write_timeoutde la base de données source (généralement, vous devez augmenter la valeur jusqu'à ce que l'erreur de connexion cesse).
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 une tâche 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 cesse 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 l'interface utilisateur de Cloud Monitoring.
- Les erreurs du thread d'E/S MySQL ou du thread SQL sont disponibles dans Cloud Logging, depuis 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 status. Pour en savoir plus, consultez la section Instruction d'état dans la documentation MySQL.Si 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_Errors'affiche, cela peut être dû à un paramètre de conservation du journal binaire insuffisant sur l'instance source.Si l'erreur
error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIESs'affiche, cela peut être dû à l'échec de la reconnexion de l'instance de destination à 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é s'est produit 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 à partir d'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 à partir d'une base de données source gérée sans droits SUPERUSER nécessite un bref temps d'arrêt 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
Un message d'erreur indique un problème avec les journaux binaires.
Cause possible
Cela peut se produire pour les tâches de migration MySQL continues 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 indique un problème avec le fichier de dump.
Cause possible
DMS ne parvient pas à trouver le fichier de dump fourni.
Solutions possibles
- Vérifiez le chemin d'accès au fichier de dump pour vous assurer qu'un fichier approprié est présent ou modifiez le chemin d'accès.
- Si vous modifiez le chemin, utilisez une requête
PATCHpour vous assurer que la tâche l'utilise. - Redémarrez la tâche 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 pause pendant des périodes qui approchent la période de conservation du journal binaire.
Solutions possibles
Redémarrez la tâche de migration.
Échec de l'exécution de la tâche de migration en raison de versions de base de données source et de destination incompatibles
La combinaison des versions de base de données source et cible n'est pas prise en charge.
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 ou supérieure d'une version majeure à la version de destination source, puis créez une tâche 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 parvient pas à établir de connexion avec le 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'affichent lorsque vous définissez les paramètres de votre tâche de migration.
L'espace disque de l'instance de destination Cloud SQL passe à zéro
L'espace disque utilisé passe soudainement à zéro pendant la migration.
Cause possible
Une erreur peut se produire lors de l'importation des données de vidage complètes. Dans ce cas, le processus de migration tente d'effectuer un autre chargement des données. Ce processus efface d'abord les données existantes sur l'instance de destination (c'est pourquoi l'espace disque passe à 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 :
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.