Data Transmission Service:Problèmes liés à la migration de données

Q : Les données de la base de données source existent-elles toujours après l'exécution d'une tâche de migration de données ?

R : La migration et la synchronisation des données DTS copient les données de la base de données source vers la base de données de destination sans affecter les données de la source.

Q : Quelles instances de base de données DTS prend-il en charge pour la migration ?

R : DTS prend en charge la migration de données entre diverses sources de données, telles que les systèmes de gestion de bases de données relationnelles (SGBDR), les bases de données NoSQL et les bases de données de traitement analytique en ligne (OLAP). Pour connaître les instances de migration prises en charge, reportez-vous à la rubrique Scénarios de migration.

Q : Comment fonctionne la migration de données ?

R : Pour plus d'informations sur le fonctionnement de la migration de données, consultez la rubrique Architecture du produit et principes des fonctionnalités.

Q : Une tâche de migration de données reste longtemps à l'état Préparation. DTS parcourt-il les fichiers de la source ?

R : Oui. Après la création de la tâche, DTS envoie d'abord une requête HEAD à la source pour sonder les données, puis parcourt tous les fichiers de la source qui doivent être migrés. La migration des données ne démarre officiellement qu'une fois le parcours terminé. La phase Preparing n'affiche pas la progression de la migration. Sa durée dépend du volume de données à migrer depuis la source et aucune estimation fixe n'est disponible. Une fois le parcours terminé, la tâche passe automatiquement à la phase de migration sans aucune intervention manuelle.

Q : Puis-je modifier les objets de migration d'une tâche de migration de données ?

R : Non.

Q : Puis-je ajouter de nouvelles tables à migrer dans une tâche de migration de données ?

R : Non.

Q : Comment modifier les objets de migration, tels que les tables et les colonnes, d'une tâche de migration en cours d'exécution ?

R : Une tâche de migration ne permet pas de modifier ses objets de migration.

Q : Si je suspends une tâche de migration, puis la redémarre après un certain temps, une incohérence des données se produira-t-elle ?

R : Si la base de données source change pendant la suspension de la tâche de migration, les données de la base de données source et de la base de données de destination peuvent devenir incohérentes. Après le redémarrage de la tâche de migration et la migration des données incrémentielles vers la base de données de destination, les données de cette dernière deviennent cohérentes avec celles de la source.

Q : Une tâche de migration peut-elle être convertie en tâche de synchronisation ?

R : Non. Les différents types de tâches ne peuvent pas être convertis les uns dans les autres.

Q : Puis-je migrer uniquement les données sans migrer le schéma ?

R : Oui. Lors de la configuration de la tâche de migration, ne sélectionnez pas Schema Migration.

Q : Quelles sont les causes possibles d'incohérence des données entre la source et la destination d'une instance de migration de données ?

Q : Puis-je modifier le nom de la base de données source dans la base de données de destination pour une tâche de migration de données ?

R : Oui. Pour savoir comment modifier le nom de la base de données source dans la base de données de destination, consultez la rubrique Mappage des noms d'objets.

Q : DTS prend-il en charge la migration de données au sein d'une même instance ?

R : Oui. Pour savoir comment effectuer une migration de données au sein d'une même instance, consultez la rubrique Synchroniser ou migrer des données entre des bases de données de noms différents.

Q : DTS prend-il en charge la migration en temps réel des opérations DML ou DDL ?

Oui. Pour les données entre bases de données relationnelles, les opérations DML prises en charge sont INSERT, UPDATE et DELETE, et les opérations DDL prises en charge sont CREATE, DROP, ALTER, RENAME et TRUNCATE.

Q : Une instance en lecture seule peut-elle être utilisée comme instance source d'une tâche de migration ?

Q : DTS prend-il en charge la migration de données pour les bases de données et tables fragmentées (sharding) ?

R : Oui. Par exemple, vous pouvez migrer des bases de données et tables fragmentées depuis MySQL ou PolarDB for MySQL vers AnalyticDB for MySQL afin de fusionner plusieurs tables en une seule.

Q : Une tâche de migration prend-elle en charge le filtrage de certaines colonnes ou données ?

R : Oui. Vous pouvez utiliser la fonctionnalité de mappage pour exclure les colonnes qui ne doivent pas être migrées, et utiliser les conditions SQL WHERE pour filtrer les données à migrer. Pour plus d'informations, consultez les rubriques Synchroniser ou migrer des colonnes spécifiques et Filtrer les données à migrer.

Q : Pourquoi la quantité de données sur l'instance de destination est-elle inférieure à celle de l'instance source après la fin de la tâche de migration ?

R : Si des données ont été filtrées lors de la migration, ou s'il existe de nombreux fragments de table dans l'instance source, la quantité de données sur l'instance de destination peut être inférieure à celle de l'instance source une fois la migration terminée.

Q : Pourquoi la valeur « Terminé » affichée par la tâche de migration dépasse-t-elle le total ?

R : Le total affiché est une valeur estimée. Une fois la tâche de migration terminée, le total est ajusté à la valeur exacte.

Q : À quoi sert la table increment_trx ajoutée à la base de données de destination lors de la migration de données ?

R : Lors de la migration de données, une table increment_trx est ajoutée à la base de données de destination. Il s'agit d'une table de point de contrôle que DTS crée dans l'instance de destination pour la migration incrémentielle. Elle sert à enregistrer le point de contrôle de la migration incrémentielle et à prendre en charge la reprise après un redémarrage anormal de la tâche. Ne supprimez pas cette table pendant la migration, sous peine d'échec de celle-ci.

Q : Une tâche de migration de données prend-elle en charge la reprise lors de la phase de migration complète des données ?

R : Oui. Si vous suspendez la tâche pendant la phase de migration complète des données, puis la redémarrez, la tâche reprend là où elle s'était arrêtée et n'a pas besoin de recommencer depuis le début.

Q : Comment migrer une instance non Alibaba Cloud vers Alibaba Cloud ?

R : Pour savoir comment migrer une instance non Alibaba Cloud vers Alibaba Cloud, consultez la rubrique Migrer des données d'un cloud tiers vers Alibaba Cloud.

Q : Comment migrer une base de données Oracle locale vers PolarDB ?

R : Pour savoir comment migrer une base de données Oracle locale vers PolarDB, consultez la rubrique Migrer une base de données Oracle autonome vers PolarDB for PostgreSQL (compatible avec Oracle).

Q : Puis-je suspendre une tâche de migration de données qui n'a pas terminé la phase de migration complète des données ?

R : Oui.

Q : Comment migrer un sous-ensemble de données d'ApsaraDB RDS for MySQL vers une base de données MySQL autonome ?

R : Lors de la configuration de la tâche de migration, vous pouvez sélectionner les objets à migrer dans Source Objects ou les filtrer dans Selected Objects selon vos besoins. La migration entre bases de données MySQL est similaire. Vous pouvez vous reporter à la rubrique Migrer une base de données MySQL autonome vers RDS for MySQL pour effectuer l'opération.

Q : Comment migrer des données entre des instances RDS appartenant au même compte Alibaba Cloud ?

R : DTS prend en charge la migration et la synchronisation entre les instances RDS. Pour la procédure de configuration, consultez le document de configuration pertinent dans la rubrique Scénarios de migration.

Q : Une alerte IOPS est déclenchée sur la base de données source immédiatement après le démarrage de la tâche de migration. Comment maintenir la stabilité des charges de travail sur la base de données source ?

Q : Pourquoi une tâche de migration de données ne peut-elle pas sélectionner une base de données nommée test ?

R : La migration de données DTS ne prend pas en charge la migration des bases de données système. Sélectionnez une base de données métier que vous avez créée pour la migration.

Q : Pourquoi aucune latence n'est-elle affichée pour une instance de migration dont la base de données source est PolarDB-X 1,0 ?

R : Une instance dont la base de données source est PolarDB-X 1,0 exécute une tâche distribuée, et les métriques surveillées par DTS n'existent que dans les sous-tâches. Par conséquent, aucune information de latence n'est affichée pour les instances dont la source est PolarDB-X 1.0. Cliquez sur l'ID de l'instance et consultez les informations de latence sous Task Management > Subtask Details de l'instance.

Q : Pourquoi DTS ne peut-il pas migrer une base de données MongoDB ?

R : La base de données à migrer peut être local ou admin. DTS ne prend pas en charge l'utilisation de MongoDB admin ou local comme base de données source ou de destination.

Q : Pourquoi une tâche de migration plusieurs-vers-un signale-t-elle l'erreur DTS-071001 ?

R : Cela peut se produire si une opération DDL en ligne a été effectuée sur la base de données source pendant l'exécution de la tâche de migration plusieurs-vers-un, modifiant ainsi le schéma de la base de données source (telles que les tables), mais que les modifications correspondantes n'ont pas été appliquées manuellement à la base de données de destination.

Q : Je n'ai pas pu ajouter une liste d'autorisation lors de la configuration d'une tâche dans la version précédente de la console. Comment résoudre ce problème ?

R : Configurez la tâche dans la nouvelle version de la console.

Q : Lors de la migration de données DTS, une opération DDL a été effectuée sur la base de données source et a provoqué l'échec de la tâche. Comment résoudre ce problème ?

R : Exécutez manuellement la même instruction DDL sur la destination en fonction de la DDL effectuée sur la base de données source, puis redémarrez la tâche. Lors de la migration de données, n'utilisez pas d'outils tels que pt-online-schema-change pour effectuer des modifications DDL en ligne sur les objets de migration dans la base de données source, sous peine d'échec de la migration. Si aucune donnée autre que celle provenant de DTS n'est écrite dans la base de données de destination, vous pouvez utiliser Data Management (DMS) pour effectuer des modifications DDL en ligne.

Q : Lors de la migration de données DTS, une opération DDL a été effectuée sur la base de données de destination et a provoqué l'échec de la tâche. Comment résoudre ce problème ?

R : Si une base de données ou une table de la base de données de destination est supprimée pendant la migration incrémentielle effectuée par DTS, la tâche devient anormale. Vous pouvez reconfigurer la tâche et exclure la base de données ou la table ayant provoqué l'échec des objets de migration.

Q : Une tâche de migration peut-elle être récupérée après sa libération ? La cohérence des données peut-elle être assurée en reconfigurant la tâche ?

R : Une tâche de migration ne peut pas être récupérée après sa libération. Lorsque vous reconfigurez la tâche, si vous ne sélectionnez pas Full Data Migration, les données ajoutées entre le moment où la tâche est libérée et le moment où la nouvelle tâche démarre ne peuvent pas être migrées vers la base de données de destination, et la cohérence des données ne peut pas être assurée. Si votre activité exige une grande précision des données, vous pouvez supprimer les données de la base de données de destination, reconfigurer la tâche de migration et sélectionner conjointement Schema Migration, Incremental Data Migration et Full Data Migration dans Task Stages.

Q : Une tâche de migration complète des données DTS n'avance plus depuis longtemps. Comment résoudre ce problème ?

R : Si les tables à migrer n'ont pas de clés primaires, la migration complète des données est très lente. Nous vous recommandons d'ajouter des clés primaires aux tables à migrer dans la base de données source avant d'effectuer la migration.

Q : Lors de la migration de données pour des tables portant le même nom, DTS prend-il en charge le transfert des données de la table source uniquement lorsque les données correspondantes n'existent pas dans la table de destination ?

R : Oui. Lors de la configuration de la tâche, vous pouvez définir Processing Mode of Conflicting Tables sur Ignore Errors and Proceed. Lorsque les schémas de table sont cohérents, si la base de données de destination rencontre un enregistrement ayant la même valeur de clé primaire qu'un enregistrement de la base de données source lors de la migration complète des données, l'enregistrement de la base de données source n'est pas migré vers la base de données de destination.

Q : Comment configurer une tâche de migration inter-comptes ?

R : Vous devez d'abord comprendre les Scénarios pour les tâches inter-comptes, puis utiliser le compte Alibaba Cloud auquel appartient l'instance de base de données pour Configurer l'autorisation RAM pour les tâches DTS inter-comptes, et enfin Configurer une tâche DTS inter-comptes.

Q : Comment une tâche de migration de données se connecte-t-elle à une base de données locale ?

R : Vous pouvez configurer la tâche de migration en définissant la Access Method de la base de données locale sur Public IP Address. Pour un exemple de procédure, consultez la rubrique Migrer une base de données MySQL autonome vers RDS for MySQL.

Q : La migration de données échoue avec l'erreur DTS-31008. Comment résoudre ce problème ?

R : Vous pouvez cliquez sur View Cause ou trouver la solution dans la rubrique Présentation des erreurs courantes en fonction du message d'erreur.

Q : Le réseau est inaccessible lorsque j'utilise Express Connect pour accéder à une base de données autonome. Comment résoudre ce problème ?

R : Vérifiez si le circuit Express Connect est correctement configuré avec la liste d'autorisation d'adresses IP liée à DTS. Pour la liste des adresses IP à ajouter à la liste d'autorisation, consultez la rubrique Ajouter les plages d'adresses IP DTS à la liste d'autorisation de votre base de données créée par l'utilisateur.

Q : Pour une tâche de migration dont la source est SQL Server, DTS prend-il en charge la migration des fonctions ?

R : Non. Si la granularité des objets de migration sélectionnés est la table, les autres objets (tels que les vues, les déclencheurs et les procédures stockées) ne sont pas non plus migrés vers la base de données de destination.

Q : La migration complète des données DTS est lente. Comment résoudre ce problème ?

R : Le volume de données à migrer peut être important. Veuillez patienter. Vous pouvez accéder à la page des détails de la tâche et consulter la progression de la migration dans le module Full Data Migration sous Task Management.

Q : La tâche signale une erreur interne. Comment résoudre ce problème ?

R : Vous pouvez rejoindre le groupe DingTalk de communication client DTS (ID de groupe : 116655009709) sur DingTalk (télécharger le client) pour obtenir de l'aide.

Q : La migration du schéma renvoie une erreur. Comment résoudre ce problème ?

R : Cliquez sur l'ID de l'instance pour accéder à la page des détails de la tâche, consultez le message d'erreur spécifique du module de migration du schéma dans Task Management, puis résolvez le problème en fonction du message d'erreur. Pour les solutions aux erreurs courantes, consultez la rubrique Présentation des erreurs courantes.

Q : La migration du schéma et la migration complète des données sont-elles facturées ?

R : Non. Pour plus d'informations sur la facturation, consultez la rubrique Éléments facturables.

Q : Dans une tâche de migration de données entre bases de données Redis, les données zset de la destination seront-elles écrasées ?

R : Oui. Le zset de la destination est écrasé. Si une clé qui existe déjà sur la destination est identique à une clé de la source, DTS supprime d'abord le zset de la clé correspondante sur la destination, puis utilise zadd pour ajouter chaque objet de la collection zset de la source à la destination.

Q : Quel est l'impact de la migration complète des données sur la base de données source ?

R : Dans la migration complète des données DTS, les données sont d'abord fragmentées, puis les données de chaque fragment sont lues et écrites. Lors du fragmentation, les IOPS de la base de données source augmentent. Lors de la lecture des données de chaque fragment, un certain impact est exercé sur les IOPS, le CachePool et la bande passante sortante de la base de données source. Selon les pratiques DTS, ces impacts sont négligeables.

Q : Lorsque PolarDB-X 1,0 est utilisé comme source, l'instance source PolarDB-X 1,0 de la tâche de migration prend-elle en charge le scaling des nœuds (ajout ou suppression) ?

R : Non. Si un scaling des nœuds se produit sur l'instance source PolarDB-X 1,0, vous devez reconfigurer la tâche.

Q : DTS peut-il garantir l'unicité des données lors de la migration vers Kafka ?

R : Non. Étant donné que les données écrites dans Kafka sont ajoutées à la suite, des données en double peuvent apparaître lors du redémarrage de la tâche DTS ou lors de l'extraction répétée des journaux depuis la source. DTS garantit l'idempotence des données, ce qui signifie que les données sont ordonnées et que la dernière valeur des données en double est placée à la fin.

Q : Si je configure d'abord une tâche de migration complète des données, puis une tâche de migration incrémentielle des données, une incohérence des données se produira-t-elle ?

R : Une incohérence des données peut se produire. Lorsqu'une tâche de migration est configurée uniquement avec la migration incrémentielle des données, la migration des données ne démarre qu'après le lancement de la tâche de migration incrémentielle. Avant le démarrage de la tâche de migration incrémentielle, les données incrémentielles générées sur l'instance source ne sont pas synchronisées avec l'instance de destination. Si vous devez effectuer une migration sans interruption de service, nous vous recommandons de sélectionner la migration du schéma, la migration complète des données et la migration incrémentielle des données comme types de migration lors de la configuration de la tâche.

Q : Dois-je sélectionner la migration du schéma lors de la configuration d'une tâche de migration incrémentielle ?

R : La migration du schéma migre les définitions des objets de migration vers l'instance de destination avant le début de la migration des données. Par exemple, elle migre la définition de la table A vers l'instance de destination. Si vous devez effectuer une migration incrémentielle, afin de garantir la cohérence des données, nous vous recommandons de sélectionner conjointement la migration du schéma, la migration complète des données et la migration incrémentielle des données.

Q : Pourquoi l'instance RDS utilise-t-elle plus d'espace de stockage que la base de données source lors de la migration d'une base de données auto-gérée vers RDS ?

R : DTS effectue une migration logique. Il encapsule les données à migrer dans des instructions SQL, puis les migre vers l'instance RDS de destination. Au cours de ce processus, des données binlog sont générées sur l'instance RDS de destination. Par conséquent, pendant la migration, l'espace de stockage utilisé par l'instance RDS peut être supérieur à celui de la base de données source.

Q : DTS prend-il en charge la migration pour les bases de données MongoDB dans un VPC ?

R : Oui. DTS prend en charge l'utilisation d'ApsaraDB for MongoDB dans un VPC comme base de données source d'une migration.

Q : Qu'advient-il des données migrées si la base de données source change pendant la migration des données ?

R : Si la tâche de migration est configurée avec la migration de schéma, la migration complète des données et la migration incrémentielle des données, toutes les modifications de données sur la base de données source pendant la migration sont migrées vers la base de données de destination par DTS.

Q : La libération d'une tâche de migration terminée affecte-t-elle l'utilisation des bases de données impliquées dans la migration ?

R : Non. Une fois la tâche de migration terminée (lorsque le Status est Completed), vous pouvez libérer la tâche de migration en toute sécurité.

Q : DTS prend-il en charge la migration incrémentielle pour MongoDB ?

R : Oui. Pour des exemples de configuration connexes, consultez Scénarios de migration.

Q : Quelle est la différence entre l'utilisation d'une instance RDS comme source d'une tâche de migration et l'utilisation d'une instance de base de données auto-gérée accessible via Internet ?

R : Si vous sélectionnez une instance RDS lors de la configuration de la tâche de migration, lorsque l'instance RDS subit des modifications telles que des modifications DNS ou un changement de type de réseau, la tâche de migration DTS peut s'adapter automatiquement, ce qui garantit efficacement la fiabilité du lien.

Q : DTS prend-il en charge la migration d'une base de données auto-gérée sur une instance ECS dans un VPC vers une instance RDS ?

Q : DTS verrouille-t-il les tables pendant la migration ? Y a-t-il un impact sur la base de données source ?

R : DTS ne verrouille pas les tables sur la base de données source ni pendant la migration complète des données ni pendant la migration incrémentielle des données. Pendant la migration complète et incrémentielle des données, les tables de données sur la source peuvent toujours être lues et écrites normalement.

Q : Lorsque DTS migre des données pour une instance RDS, extrait-il les données de l'instance principale ou secondaire ?

R : Lorsque DTS effectue une migration de données, il extrait les données de l'instance principale de l'instance RDS.

Q : DTS prend-il en charge la migration automatique planifiée ?

R : DTS ne prend actuellement pas en charge la planification du démarrage des tâches de migration de données.

Q : DTS prend-il en charge la migration de données pour les instances RDS en mode VPC ?

R : Oui. Lors de la configuration de la tâche de migration, spécifiez directement l'ID de l'instance RDS.

Q : Lorsque DTS effectue une migration ou une synchronisation au sein du même compte ou entre comptes, utilise-t-il le réseau interne ou Internet pour les instances ECS et RDS ? Des frais de trafic sont-ils facturés ?

Q : Lorsque j'utilise DTS pour la migration de données, les données de la base de données source seront-elles supprimées après la migration ?

R : Non. Lorsque DTS effectue une migration de données, il copie les données de la base de données source vers la base de données de destination et n'affecte pas les données de la base de données source.

Q : Lorsque DTS effectue une migration de données entre des instances RDS, puis-je spécifier le nom de la base de données de destination ?

R : Oui. Lorsque vous effectuez une migration de données entre des instances RDS, vous pouvez utiliser la fonctionnalité de mappage de noms de base de données fournie par DTS pour spécifier le nom de la base de données de destination. Pour plus d'informations, consultez Synchroniser ou migrer des données entre des bases de données de noms différents.

Q : La source d'une tâche de migration DTS ne peut pas se connecter à une instance ECS. Comment résoudre ce problème ?

R : L'instance ECS peut ne pas avoir d'adresse IP publique activée. Associez une adresse IP élastique (EIP) à l'instance ECS et réessayez. Pour savoir comment associer une EIP, consultez EIP.

Q : Pourquoi une tâche de migration entre bases de données Redis n'affiche-t-elle pas la migration complète des données ?

R : La migration entre bases de données Redis prend en charge à la fois la migration complète des données et la migration incrémentielle des données, qui sont combinées et affichées sous la forme Incremental Data Migration.

Q : La migration complète des données peut-elle être ignorée ?

R : Oui. Après avoir ignoré la migration complète des données, la migration incrémentielle continue. Cependant, des erreurs peuvent se produire. Nous vous recommandons de ne pas ignorer la migration complète des données.

Q : L'édition cluster de Redis prend-elle en charge l'accès à DTS via Internet ?

R : Non. Actuellement, seule l'édition autonome de Redis prend en charge l'accès aux instances de migration DTS via Internet.

Q : À quoi dois-je faire attention lors de la migration des données de MySQL 8.0 vers MySQL 5.6 ?

R : Vous devez créer les bases de données dans MySQL 5.6 avant d'effectuer la migration. Nous vous recommandons de conserver les mêmes versions de base de données source et de destination, ou de migrer d'une version inférieure vers une version supérieure pour garantir la compatibilité. La migration d'une version supérieure vers une version inférieure peut entraîner des problèmes de compatibilité de base de données.

Q : Puis-je migrer les comptes de la base de données source vers la base de données de destination ?

R : Actuellement, seules les tâches de migration entre instances ApsaraDB RDS for MySQL prennent en charge la migration des comptes. Les autres tâches de migration ne le prennent pas en charge.

Q : Comment configurer les paramètres lorsque ApsaraMQ for Kafka est la destination ?

R : Configurez les paramètres en fonction de votre scénario réel. Pour savoir comment configurer certains paramètres spéciaux, consultez Configurer les paramètres de l'instance Kafka.

Q : Comment effectuer une migration complète des données planifiée ?

R : Vous pouvez utiliser la configuration de la politique de planification de la fonctionnalité Data Integration pour migrer périodiquement le schéma et les données existantes de la base de données source vers la base de données de destination. Pour plus d'informations, consultez Configurer une tâche d'intégration de données entre instances RDS for MySQL.

Q : DTS prend-il en charge la migration d'un SQL Server auto-géré sur une instance ECS vers un SQL Server auto-géré dans un centre de données sur site ?

R : Oui. Le SQL Server auto-géré dans le centre de données sur site doit être connecté à Alibaba Cloud. Pour plus d'informations, consultez Aperçu de la préparation.

Q : DTS prend-il en charge la migration d'une base de données PostgreSQL depuis un autre cloud ?

Si la base de données PostgreSQL sur un autre cloud est configurée pour permettre à DTS d'y accéder via Internet, vous pouvez utiliser DTS pour migrer les données.

Q : DTS prend-il en charge la migration des données de MySQL vers Mycat ?

R : Oui. Vous pouvez connecter Mycat à Alibaba Cloud en tant que base de données MySQL auto-gérée, puis utiliser DTS pour migrer les données.

Q : Pendant la migration des données, DTS prend-il en charge la migration incrémentielle des opérations DDL ?

R : Cela est pris en charge dans certains scénarios de migration. Pour plus d'informations, consultez Notes d'utilisation et limites pour la migration de données.

Q : Les déclencheurs (TRIGGER) sont manquants dans la base de données de destination après la migration

• Cause : Le compte de base de données source utilisé par la tâche DTS manque du privilège EVENT ou du privilège SELECT sur la table information_schema.TRIGGERS . Par conséquent, DTS ne peut pas lire les métadonnées des déclencheurs et ignore la synchronisation des déclencheurs.

• Solution :

  • Méthode 1 : Après avoir confirmé que le compte de base de données source a reçu les privilèges requis (le privilège EVENT et le privilège SELECT sur la table information_schema.TRIGGERS ), relancez la migration de schéma.

  • Méthode 2 : Créez manuellement les déclencheurs manquants dans la base de données de destination.

Q : Description de la conversion automatique de l'attribut DEFINER lors de la migration des procédures stockées

R : Lorsque DTS migre des procédures stockées, il convertit automatiquement l'attribut DEFINER de la procédure stockée source en compte de base de données de destination et change le mode SQL SECURITY en INVOKER . Il s'agit d'un comportement standardisé conçu pour garantir que les procédures stockées migrées puissent être exécutées correctement dans la portée des autorisations du compte de base de données de destination.

• Si cette conversion provoque une erreur de vérification de schéma mais que la fonctionnalité de la procédure stockée elle-même n'est pas affectée, vous pouvez choisir d'ignorer l'erreur.

• Si votre activité nécessite de restaurer l'attribut DEFINER d'origine sur la destination, vous devez supprimer manuellement la procédure stockée sur la destination, puis la recréer en utilisant un compte disposant des privilèges requis.

Q : Quel est l'impact de la modification des données dans la base de données de destination pendant l'exécution d'une tâche de synchronisation ou de migration de données ?

• La modification des données dans la base de données de destination peut entraîner l'échec de la tâche DTS. Pendant la migration ou la synchronisation des données, l'exécution d'opérations sur les objets en cours de migration ou de synchronisation dans la base de données de destination peut provoquer des problèmes tels que des conflits de clés primaires ou des enregistrements de mise à jour manquants, ce qui entraîne finalement l'échec de la tâche DTS. Cependant, vous pouvez effectuer des opérations qui n'interrompent pas la tâche DTS. Par exemple, si vous créez une table dans l'instance de destination et y écrivez des données, la tâche DTS n'est pas affectée car la table n'est pas incluse dans les objets de migration ou de synchronisation.

• Étant donné que DTS lit les informations de la base de données de l'instance source et migre ou synchronise ses données complètes, ses données de schéma et ses données incrémentielles vers l'instance de destination, les modifications de données apportées à la base de données de destination pendant la tâche peuvent être écrasées par les données migrées ou synchronisées depuis la base de données source.

Q : DTS prend-il en charge la migration de données ou la synchronisation de données inter-comptes ?

R : Oui. Pour savoir comment le configurer, consultez Configurer une tâche DTS inter-comptes.

Q : Les données peuvent-elles être écrites simultanément dans la base de données source et la base de données de destination pendant l'exécution d'une tâche de synchronisation ou de migration de données ?

R : Oui. Cependant, pendant l'exécution de l'instance DTS, si des sources de données autres que DTS écrivent des données dans la base de données de destination, des anomalies peuvent se produire dans les données de la base de données de destination ou dans l'instance DTS.

Q : DTS prend-il en charge la synchronisation ou la migration d'échantillons de données par plage horaire ?

R : Non.

Q : Lors de la synchronisation ou de la migration de données, dois-je créer manuellement des tables dans la base de données de destination ?

R : Pour les instances DTS qui prennent en charge les tâches de schéma (synchronisation de schéma ou migration de schéma), si vous avez configuré une tâche de schéma (Synchronization Types avec Schema Synchronization sélectionné, ou Migration Types avec Schema Migration sélectionné), vous n'avez pas besoin de créer manuellement des tables dans la base de données de destination.

Q : Lors de la synchronisation ou de la migration de données, la base de données source et la base de données de destination doivent-elles être connectées via le réseau ?

R : Non.

Q : Comment utiliser l'API pour configurer la fonctionnalité ETL pour une tâche de synchronisation ou de migration ?

R : Vous pouvez la configurer dans le paramètre Reserve de l'API en utilisant des paramètres communs tels que etlOperatorCtl et etlOperatorSetting. Pour plus d'informations, consultez ConfigureDtsJob et Référence du paramètre Reserve.

Q : Les données de la base de données source sont-elles conservées après la fin de la synchronisation ou de la migration DTS ?

R : Oui. DTS ne supprime pas les données de la base de données source. Si vous n'avez pas besoin de conserver les données de la base de données source, supprimez-les manuellement.

Q : Puis-je ajuster le débit après le démarrage d'une instance de synchronisation ou de migration ?

R : Oui. Pour plus d'informations, consultez Activer la limitation de débit pour la migration de données.

Q : Une erreur de synchronisation incrémentielle indique que le paquet est trop volumineux ou que la valeur max_allowed_packet à la destination est insuffisante. Comment résoudre ce problème ?

• Cause :

  La source contient une ligne avec une grande quantité de données qui dépasse la limite du paramètre max_allowed_packet à la destination pendant la synchronisation incrémentielle, ce qui provoque l'erreur de synchronisation.

• Solution :

  1. Connectez-vous à la base de données source et interrogez la valeur actuelle du paramètre max_allowed_packet :

     SHOW VARIABLES LIKE 'max_allowed_packet';

     Enregistrez la valeur (par exemple, 1073741824 , soit 1 Go).

  2. Connectez-vous à la console ApsaraDB RDS (ou à la console PolarDB si la destination est PolarDB for MySQL). Sur la page Parameters de l'instance de base de données de destination, définissez le paramètre max_allowed_packet sur une valeur supérieure ou égale à celle de la source.

  3. Une fois la modification du paramètre terminée, redémarrez la tâche de synchronisation dans la console DTS et vérifiez si la synchronisation revient à la normale.

Q : La tâche de synchronisation a été interrompue pendant plusieurs heures et je soupçonne qu'un verrou MDL existe à la destination. Comment résoudre ce problème ?

• Cause :

  Un verrou de métadonnées (verrou MDL) à la destination, causé par une opération DDL de longue durée (comme l'ajout d'une colonne à une grande table ou la reconstruction d'un index), bloque les écritures de données incrémentielles de DTS, ce qui interrompt le lien de synchronisation pendant une longue période.

• Solution :

  1. Connectez-vous à la console ApsaraDB RDS, accédez à l'instance de base de données de destination et exécutez SHOW FULL PROCESSLIST pour localiser la session anormale qui détient le verrou MDL. Ensuite, tuez la session.

  2. Connectez-vous à la console DTS et modifiez les objets de synchronisation pour retirer les tables affectées par le verrou MDL de la portée de synchronisation.

  3. Supprimez la table dans la base de données de destination (avant cette opération, assurez-vous que les données ont été sauvegardées ou peuvent être effacées).

  4. Une fois que la tâche de synchronisation DTS revient à la normale et que la latence de synchronisation tombe à zéro, modifiez à nouveau les objets de synchronisation pour rajouter la table à la portée de synchronisation et terminer la re-migration.

Q : Une erreur de synchronisation incrémentielle indique qu'une table temporaire est manquante dans la base de données de destination ou qu'un conflit SELECT INTO se produit. Comment résoudre ce problème ?

• Cause :

  Ce problème n'est pas réellement causé par une table temporaire manquante dans la base de données de destination. Au lieu de cela, après l'activation de Change Data Capture (CDC) dans la base de données source, les déclencheurs créés par DTS interceptent la création implicite de table effectuée par SELECT INTO , ce qui provoque des conflits pendant la synchronisation des données.

• Solution :

  1. Vérifiez que le fichier journal des transactions à la source existe et est intact.

  2. Désactivez la fonctionnalité CDC dans la base de données source.

  3. Connectez-vous à la console DTS, reconfigurez la tâche de synchronisation, sélectionnez Parse source database logs comme méthode de synchronisation incrémentielle, puis redémarrez la tâche.

Q : Lorsque vous utilisez DTS pour la synchronisation ou la migration de données, les données existantes à la destination sont-elles écrasées ?

R : En prenant la synchronisation des données comme exemple, le comportement par défaut et les paramètres connexes de DTS sont les suivants :