Tous les produits
Search

Ce produit

    Data Transmission Service:Migrer RDS for MySQL vers PolarDB for MySQL

    Centre de documentation

    Data Transmission Service:Migrer RDS for MySQL vers PolarDB for MySQL

    Dernière mise à jour :Aug 10, 2026

    Utilisez Data Transmission Service (DTS) pour migrer les données d'une base de données MySQL vers un cluster PolarDB for MySQL.

    Bases de données sources prises en charge

    La base de données MySQL source peut être de l'un des types suivants. Cette rubrique utilise une instance ApsaraDB RDS for MySQL comme exemple. Le processus de configuration pour les autres types de bases de données sources est similaire.

    • Instances ApsaraDB RDS for MySQL.

    • Bases de données auto-gérées :

      • Base de données auto-gérée avec une adresse IP publique

      • Base de données auto-gérée hébergée sur Elastic Compute Service (ECS)

      • Base de données auto-gérée connectée via Express Connect, VPN Gateway ou Smart Access Gateway

      • Base de données auto-gérée connectée via Database Gateway

    Prérequis

    Limites

    Remarque

    Type

    Description

    Limites de la base de données source

    • Exigence de bande passante : le serveur qui héberge la base de données source doit disposer d'une bande passante sortante suffisante. Dans le cas contraire, le taux de migration des données sera affecté.

    • Les tables à migrer doivent posséder une clé primaire ou une contrainte unique dont les valeurs de colonne sont uniques. À défaut, des données en double risquent d'être générées dans la base de données de destination.

    • Si les objets de migration sont au niveau des tables et que vous devez les modifier (par exemple, pour mapper les noms de colonnes), une seule tâche de migration prend en charge au maximum 1 000 tables. Si ce nombre est dépassé, une erreur s'affiche lors de la soumission de la tâche. Dans ce cas, divisez les tables à migrer et configurez la migration dans plusieurs tâches, ou configurez une tâche de migration au niveau de la base de données.

    • Si vous effectuez une migration incrémentielle, les journaux binaires doivent répondre aux exigences suivantes :

      • La journalisation binaire doit être activée, avec binlog_format défini sur row et binlog_row_image défini sur full. Sinon, la pré-vérification signale une erreur et la tâche de migration des données ne peut pas démarrer.

        Important

        Si l'instance source MySQL auto-gérée est un cluster à double maître (les deux serveurs sont à la fois maîtres et réplicas l'un de l'autre), activez le paramètre log_slave_updates afin de garantir que DTS capture tous les journaux binaires.

      • Les instances ApsaraDB RDS for MySQL doivent conserver les journaux binaires locaux pendant au moins trois jours (sept jours sont recommandés). Les bases de données MySQL auto-gérées doivent conserver les journaux binaires locaux pendant au moins sept jours. Sinon, DTS risque de ne pas pouvoir récupérer les journaux binaires et la tâche peut échouer. Dans des cas extrêmes, cela peut entraîner une incohérence ou une perte de données. Les problèmes causés par la définition d'une durée de rétention des journaux binaires inférieure à l'exigence de DTS ne sont pas couverts par le SLA de DTS.

        Remarque

        Pour savoir comment configurer la retention period des journaux binaires locaux sur une instance ApsaraDB RDS for MySQL, consultez la rubrique Configurer la suppression automatique (politique de conservation des journaux locaux).

    • Restrictions concernant les opérations sur la base de données source :

      • Pendant les phases de migration du schéma et de migration complète des données, n'effectuez pas d'opérations DDL qui modifient les schémas de base de données ou de tables. Cela provoquerait l'échec de la tâche de migration des données.

        Remarque

        Lors de la phase de migration complète des données, DTS interroge la base de données source, ce qui génère des verrous de métadonnées susceptibles de bloquer les opérations DDL sur la base de données source.

      • Si vous effectuez uniquement une migration complète des données, n'écrivez pas de nouvelles données dans l'instance source. Cela entraînerait une incohérence des données entre la source et la destination. Pour maintenir la cohérence des données en temps réel, 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.

    • Tant que l'instance de migration est en cours d'exécution, les données générées par des opérations qui ne sont pas écrites dans le journal binaire (telles que les données restaurées par sauvegarde physique ou générées par des opérations en cascade) ne sont pas migrées vers la base de données de destination.

      Remarque

      Si cela se produit et que votre activité le permet, relancez une migration complète des données.

    • Si la base de données source est une version MySQL 8.0.23 ou ultérieure et que les données à migrer contiennent des colonnes invisibles, une perte de données peut survenir car DTS ne peut pas extraire les données de ces colonnes.

      Remarque

      Vous pouvez utiliser l'instruction ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour rendre une colonne invisible visible. Pour plus d'informations, consultez la documentation Invisible Columns.

    • Compatibilité MySQL : Lorsque DTS migre des données depuis une base de données source de la famille MySQL, il s'appuie sur le protocole MySQL standard et le format de journal binaire. Les comportements non compatibles avec MySQL standard ne sont pas pris en charge. Si votre base de données source prétend être compatible avec MySQL mais se comporte différemment (par exemple, lorsqu'OceanBase agit comme une base de données source compatible MySQL, l'horodatage de l'événement de rotation à la fin du journal binaire est 0, ce qui est incompatible avec MySQL), la tâche de migration DTS peut échouer de manière inattendue.

    Autres limites

    • Nous vous recommandons d'utiliser la même version de MySQL pour les bases de données source et de destination afin d'assurer la compatibilité.

    • Si votre base de données source utilise des opérations DDL en ligne en mode table temporaire — y compris dans des scénarios de fusion multi-tables — ou ajoute des index basés sur des fonctions aux colonnes de clé unique, une perte de données ou un échec de la tâche peut survenir sur la base de données de destination.

    • Les analyseurs définis à l'aide de la syntaxe de commentaire ne peuvent pas être migrés.

    • En cas de conflit de clé primaire ou de clé unique lors de la migration :

      • Si les schémas de table sont cohérents et qu'un enregistrement de la base de données de destination possède la même valeur de clé primaire qu'un enregistrement de la base de données source :

        • Lors de la migration complète, DTS conserve l'enregistrement dans la base de données de destination. L'enregistrement provenant de la base de données source n'est pas migré.

        • Lors de la migration incrémentielle, DTS ne conserve pas l'enregistrement dans la base de données de destination. L'enregistrement provenant de la base de données source écrase l'enregistrement dans la base de données de destination.

      • Si les schémas de table sont incohérents, seules certaines colonnes de données peuvent être migrées, ou la migration peut échouer. Procédez avec prudence.

    • Avant la migration, évaluez les performances des bases de données source et de destination. Nous vous recommandons de migrer les données pendant les heures creuses, car DTS consomme des ressources de lecture et d'écriture sur les deux bases de données lors de la migration complète des données, ce qui peut augmenter la charge de la base de données.

    • Étant donné que la migration complète des données exécute des opérations INSERT concurrentes, une fragmentation des tables se produit dans la base de données de destination. Après la migration complète des données, l'espace de stockage des tables dans la base de données de destination est supérieur à celui de l'instance source.

    • Si les données à migrer contiennent du contenu nécessitant un stockage sur quatre octets (tel que des caractères rares ou des emojis), la base de données de destination et les tables qui reçoivent les données doivent utiliser le jeu de caractères utf8mb4.

      Remarque

      Si vous utilisez DTS pour migrer le schéma, définissez le paramètre au niveau de l'instance character_set_server sur utf8mb4 dans la base de données de destination.

    • Vérifiez si la précision de migration appliquée par DTS aux colonnes FLOAT et DOUBLE répond à vos besoins métier. DTS lit les valeurs de ces colonnes en appelant ROUND(COLUMN,PRECISION). Si la précision n'est pas explicitement définie, DTS migre FLOAT avec une précision de 38 chiffres et DOUBLE avec une précision de 308 chiffres.

    • DTS tente de reprendre les tâches de migration ayant échoué dans un délai de sept jours. Par conséquent, avant de basculer votre activité vers l'instance de destination, terminez ou libérez la tâche, ou exécutez la commande revoke pour révoquer les autorisations d'écriture du compte utilisé par DTS pour accéder à l'instance de destination. Cela empêche la tâche de reprendre automatiquement et d'écraser les données de l'instance de destination avec celles de la source.

    • DTS ne prend pas en charge la conversion des données datetime en varchar.

    • Si une instruction DDL échoue à s'écrire dans la base de données de destination, la tâche DTS continue de s'exécuter. Vous devez consulter l'instruction DDL ayant échoué dans le journal de la tâche. Pour savoir comment afficher le journal de la tâche, consultez la rubrique Afficher les journaux de tâche.

    • Si Fully Encrypted Database (EncDB) est activé sur une instance RDS MySQL, la migration complète des données n'est pas prise en charge.

      Remarque

      Les instances RDS MySQL avec Transparent Data Encryption (TDE) activé prennent en charge la migration du schéma, la migration complète des données et la migration incrémentielle des données.

    • Pour migrer les comptes depuis la base de données source, vous devez satisfaire aux prérequis applicables et comprendre les considérations connexes. Pour plus d'informations, consultez la rubrique Migrer les comptes de base de données.

    • Si une tâche échoue, l'équipe d'assistance DTS tentera de la restaurer dans un délai de huit heures. Lors de la restauration, elle peut redémarrer la tâche ou ajuster ses paramètres.

      Remarque

      Seuls les paramètres de la tâche DTS sont modifiés, et non les paramètres de la base de données. Les paramètres susceptibles d'être ajustés incluent ceux répertoriés dans la rubrique Modifier les paramètres de l'instance.

    Cas particuliers

    • Lorsque la base de données source est une base de données MySQL auto-gérée :

      • Si la base de données source effectue un basculement primaire/secondaire pendant la migration, la tâche de migration échoue.

      • La latence de migration signalée par DTS correspond à la différence entre l'horodatage des dernières données migrées vers la base de données de destination et l'horodatage actuel. Si la base de données source n'a pas effectué d'opérations DML depuis longtemps, la latence signalée peut être inexacte. Si la latence affichée semble trop élevée, exécutez une opération DML sur la base de données source pour mettre à jour la latence.

        Remarque

        Si vous migrez une base de données entière, vous pouvez également créer une table de heartbeat qui est mise à jour ou écrite à intervalles réguliers (par exemple, chaque seconde).

      • DTS exécute périodiquement l'instruction CREATE DATABASE IF NOT EXISTS test sur la base de données source pour faire avancer la position du journal binaire.

      • Si la base de données source est Amazon Aurora MySQL ou un autre mode cluster MySQL, assurez-vous que le nom de domaine ou l'adresse IP configuré pour la tâche — ainsi que sa résolution DNS — résolvent toujours vers un nœud en lecture/écriture (RW). Sinon, la tâche de migration risque de ne pas s'exécuter correctement.

    • Lorsque la base de données source est RDS MySQL :

      • Pour migrer des données incrémentielles, les instances RDS MySQL qui n'enregistrent pas les journaux de transactions (telles que les instances en lecture seule de RDS MySQL 5.6) ne peuvent pas être utilisées comme bases de données sources.

      • DTS exécute périodiquement l'instruction CREATE DATABASE IF NOT EXISTS test sur la base de données source pour faire avancer la position du journal binaire.

    • Lorsque la base de données de destination est PolarDB MySQL Edition :

      • DTS crée automatiquement une base de données dans PolarDB for MySQL. Si le nom de la base de données à migrer ne respecte pas les conventions de nommage de PolarDB for MySQL, vous devez créer la base de données dans PolarDB for MySQL avant de configurer la tâche de migration. Pour les opérations associées, consultez la rubrique Gérer les bases de données.

      • Vous ne pouvez pas ajuster le débit de migration complète.

    Facturation

    Type de migration

    Frais de configuration de l'instance

    Frais de trafic Internet

    Migration du schéma et migration complète des données

    Gratuit.

    Des frais de trafic Internet vous sont facturés lorsque la Access Method de la base de données de destination est définie sur Public IP Address. Pour plus d'informations, consultez la rubrique Présentation de la facturation.

    Migration incrémentielle des données

    Facturé. Pour plus d'informations, consultez la rubrique Présentation de la facturation.

    Types de migration

    • Migration de schéma

      DTS migre les définitions de schéma des objets sélectionnés depuis la base de données source vers la base de données de destination.

      • DTS prend en charge la migration de schéma pour les tables, les vues, les déclencheurs, les procédures stockées et les fonctions.

        Remarque

        Le routine_body des procédures stockées, le routine_body des fonctions et le select_statement des vues ne sont pas modifiés.

      • Lors de la migration de schéma, DTS remplace DEFINER par INVOKER pour les vues, les procédures stockées et les fonctions à migrer. Cette action définit la valeur de SQL SECURITY sur INVOKER. DTS attribue également à DEFINER le compte de la base de données de destination utilisé pour la tâche de migration.

        Remarque

        La méthode d'authentification de sécurité et le définisseur de la base de données source ne sont pas modifiés.

      • Étant donné que DTS ne migre pas les informations utilisateur, vous devez accorder des autorisations de lecture et d'écriture à l'appelant pour utiliser les vues, les procédures stockées et les fonctions dans la base de données de destination.

    • Migration complète

      DTS migre toutes les données historiques des objets sélectionnés depuis la base de données source vers la base de données de destination.

    • Migration incrémentielle

      Une fois la migration complète terminée, DTS migre les modifications de données incrémentielles de la source vers la destination. Cela permet de migrer les données sans interrompre vos applications autogérées.

    Opérations SQL pour la migration incrémentielle

    Type d'opération

    Instruction SQL

    DML

    INSERT, UPDATE, DELETE

    DDL

    • ALTER TABLE, ALTER VIEW

    • CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW

    • DROP INDEX, DROP TABLE

    • RENAME TABLE

      Important

      Une opération RENAME TABLE peut entraîner une incohérence des données. Par exemple, si vous sélectionnez une seule table comme objet de migration et que vous renommez cette table dans l'instance source pendant la migration, les données de cette table ne seront pas migrées vers la base de données de destination. Pour éviter ce problème, sélectionnez la base de données entière à laquelle la table appartient comme objet de migration lors de la configuration de la tâche de migration de données. Assurez-vous que les bases de données auxquelles la table appartient avant et après l'opération RENAME TABLE sont toutes deux incluses dans les objets de migration.

    • TRUNCATE TABLE

    Autorisations requises pour les comptes de base de données

    Base de données

    Migration de schéma

    Migration complète des données

    Migration incrémentielle des données

    ApsaraDB RDS for MySQL instance

    Autorisation SELECT

    Autorisation SELECT

    Autorisations REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW et SELECT

    PolarDB for MySQL cluster

    Autorisations de lecture et d'écriture

    Pour créer des comptes de base de données et accorder des autorisations, consultez les rubriques suivantes :

    Procédure

    1. Accédez à la page de liste des tâches de migration pour la région de destination en utilisant l'une des méthodes suivantes.

      Depuis la console DTS

      1. Connectez-vous à la Data Transmission Service (DTS) console.

      2. Dans le volet de navigation de gauche, cliquez sur Data Migration.

      3. Dans le coin supérieur gauche de la page, sélectionnez la région où se trouve l'instance de migration.

      Depuis la console DMS

      Remarque

      Les opérations réelles peuvent varier selon le mode et la disposition de la console DMS. Pour plus d'informations, consultez Console en mode simple et Personnaliser la disposition et le style de la console DMS.

      1. Connectez-vous à la Data Management (DMS) console.

      2. Dans la barre de menus supérieure, choisissez Data + AIData + AI > Data Transmission (DTS) > Data Migration.

      3. À droite de Data Migration Tasks, sélectionnez la région où se trouve l'instance de migration.

    2. Cliquez sur Create Task pour accéder à la page de configuration de la tâche.

    3. Facultatif : Dans le coin supérieur droit de la page, cliquez sur New Configuration Page.

      Remarque

      • Si vous êtes déjà sur la nouvelle page de configuration (le bouton dans le coin supérieur droit est Back to Previous Version), vous pouvez ignorer cette étape.

      • Les paramètres des anciennes et nouvelles pages de configuration diffèrent. Nous vous recommandons d'utiliser la nouvelle page de configuration.

    4. Configurez les bases de données source et de destination.

      Avertissement

      Après avoir sélectionné les instances source et de destination, lisez les Limits en haut de la page pour vous assurer que la tâche de migration peut être créée et exécutée avec succès.

      Section

      Parameter

      Description

      N/A

      Task Name

      DTS génère automatiquement un nom de tâche. Spécifiez un nom descriptif pour faciliter l'identification. Le nom n'a pas besoin d'être unique.

      Source Database

      Select a DMS database instance.

      Sélectionnez une instance existante selon vos besoins.

      • Si vous utilisez une instance existante, les informations de la base de données sont renseignées automatiquement. Vous n'avez pas besoin de les saisir à nouveau.

      • Si vous n'utilisez pas d'instance existante, configurez les informations de base de données suivantes.

      Remarque

      Database Type

      Sélectionnez MySQL.

      Connection Type

      Sélectionnez Alibaba Cloud Instance.

      Instance Region

      Sélectionnez la région de l'instance ApsaraDB RDS for MySQL source.

      Cross-account

      Cet exemple migre des données au sein du même compte Alibaba Cloud. Sélectionnez No.

      RDS Instance ID

      Sélectionnez l'ID de l'instance ApsaraDB RDS for MySQL source.

      Database Account

      Saisissez le compte de base de données de l'instance ApsaraDB RDS for MySQL source. Pour connaître les autorisations requises, consultez Autorisations requises pour les comptes de base de données.

      Database Password

      Saisissez le mot de passe du compte de base de données.

      Connection Method

      Sélectionnez Non-encrypted ou SSL-encrypted selon les exigences de votre base de données. Si vous définissez ce paramètre sur SSL-encrypted, vous devez activer le chiffrement SSL pour l'instance RDS for MySQL au préalable. Pour plus d'informations, consultez Activer rapidement le chiffrement SSL à l'aide d'un certificat cloud.

      Destination Database

      Select a DMS database instance.

      Sélectionnez une instance existante selon vos besoins.

      • Si vous utilisez une instance existante, les informations de la base de données sont renseignées automatiquement. Vous n'avez pas besoin de les saisir à nouveau.

      • Si vous n'utilisez pas d'instance existante, configurez les informations de base de données suivantes.

      Remarque

      Database Type

      Sélectionnez PolarDB for MySQL.

      Connection Type

      Sélectionnez Alibaba Cloud Instance.

      Instance Region

      Sélectionnez la région du cluster PolarDB for MySQL de destination.

      PolarDB Cluster ID

      Sélectionnez l'ID du cluster PolarDB for MySQL de destination.

      Database Account

      Saisissez le compte de base de données du cluster PolarDB for MySQL de destination. Pour connaître les autorisations requises, consultez Autorisations requises pour les comptes de base de données.

      Database Password

      Saisissez le mot de passe du compte de base de données.

      Encryption

      Sélectionnez un type de connexion selon vos besoins. Pour plus d'informations sur la fonctionnalité de chiffrement SSL, consultez Activer le chiffrement SSL.

    5. Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page.

      Si la base de données source ou de destination est une instance de base de données Alibaba Cloud, telle qu'une instance RDS for MySQL ou ApsaraDB for MongoDB, DTS ajoute automatiquement les plages CIDR des serveurs DTS à la liste d'autorisation IP de l'instance. Si la base de données source ou de destination est une base de données auto-gérée hébergée sur une instance ECS, DTS ajoute automatiquement les plages CIDR des serveurs DTS aux règles du groupe de sécurité de l'instance ECS. Vous devez également vous assurer que la base de données est accessible depuis l'instance ECS. Si la base de données auto-gérée est hébergée sur plusieurs instances ECS, vous devez ajouter manuellement les plages CIDR des serveurs DTS aux règles du groupe de sécurité de chaque instance ECS. Si la base de données source ou de destination est une base de données auto-gérée déployée dans un centre de données sur site ou fournie par un fournisseur de services cloud tiers, vous devez ajouter manuellement les plages CIDR des serveurs DTS à la liste d'autorisation IP de la base de données pour autoriser l'accès depuis les serveurs DTS. Pour plus d'informations sur les adresses IP des serveurs DTS, consultez Plages CIDR des serveurs DTS.

      Avertissement

      L'ajout des plages d'adresses IP publiques des serveurs DTS, qu'il soit automatique ou manuel, peut introduire des risques de sécurité. En utilisant ce produit, vous reconnaissez et acceptez ces risques potentiels. Vous devez mettre en œuvre des mesures de sécurité de base, telles que l'utilisation de mots de passe robustes, la limitation des ports ouverts pour chaque plage CIDR, l'utilisation de l'authentification pour les appels API internes, ainsi que la vérification et la restriction régulières des plages CIDR inutiles. Vous pouvez également vous connecter via un réseau interne, tel qu'une ligne louée, VPN Gateway ou Smart Access Gateway.

    6. Configurez les objets de la tâche.

      1. Sur la page Configure Objects, configurez les objets que vous souhaitez migrer.

        Parameter

        Description

        Migration Types

        • Si vous devez uniquement effectuer une migration complète, sélectionnez à la fois Schema Migration et Full Data Migration.

        • Pour réaliser une migration sans interruption de service, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration.

        Remarque

        • Si vous ne sélectionnez pas Schema Migration, assurez-vous qu'une base de données et des tables destinées à recevoir les données existent dans la base de données de destination. Vous pouvez également utiliser la fonctionnalité de mappage des noms d'objets dans la zone Selected Objects selon vos besoins.

        • Si vous ne sélectionnez pas Incremental Data Migration, n'écrivez aucune nouvelle donnée dans l'instance source pendant la migration afin de garantir la cohérence des données.

        Method to Migrate Triggers in Source Database

        Sélectionnez une méthode de migration des déclencheurs en fonction de vos exigences métier. Si les objets à migrer n'incluent pas de déclencheurs, vous pouvez ignorer ce paramètre. Pour plus d'informations, consultez la rubrique Configurer la synchronisation ou la migration des déclencheurs.

        Remarque

        Ce paramètre est disponible uniquement lorsque les options Migration Types et Schema Migration sont sélectionnées pour l'Incremental Data Migration.

        Processing Mode of Conflicting Tables

        • Precheck and Report Errors : vérifie si des tables portant le même nom existent dans la base de données de destination. En l'absence de tables homonymes, la prévalidation réussit. Dans le cas contraire, une erreur est signalée lors de la prévalidation et la tâche de migration des données ne démarre pas.

          Remarque

          Si une table de la base de données de destination porte le même nom mais ne peut pas être facilement supprimée ou renommée, modifiez son nom dans la base de données de destination. Pour plus d'informations, consultez la rubrique Mappage des noms d'objets.

        • Ignore Errors and Proceed : ignore la vérification des tables homonymes.

          Avertissement

          La sélection de l'option Ignore Errors and Proceed peut entraîner une incohérence des données et présenter des risques pour votre activité. Par exemple :

          • Si les schémas de table sont identiques et qu'un enregistrement de la base de données de destination possède la même valeur de clé primaire qu'un enregistrement de la base de données source :

            • Lors de la migration complète, DTS conserve l'enregistrement présent dans la base de données de destination. L'enregistrement provenant de la base de données source n'est pas migré.

            • Lors de la migration incrémentielle, DTS ne conserve pas l'enregistrement présent dans la base de données de destination. L'enregistrement provenant de la base de données source écrase celui de la base de données de destination.

          • Si les schémas de table sont différents, seules certaines colonnes de données peuvent être migrées ou la migration peut échouer. Procédez avec prudence.

        Whether to migrate Event

        Indiquez si vous souhaitez migrer les événements de la base de données source. Si vous sélectionnez Yes, des étapes supplémentaires sont requises. Consultez la rubrique Synchroniser ou migrer des événements.

        Capitalization of Object Names in Destination Instance

        Vous pouvez configurer la politique de sensibilité à la casse pour les noms des objets migrés (bases de données, tables et colonnes) dans l'instance de destination. Par défaut, l'option DTS default policy est sélectionnée. Vous pouvez également choisir de maintenir la sensibilité à la casse conformément à la politique par défaut de la base de données source ou de destination. Pour plus d'informations, consultez la rubrique Sensibilité à la casse des noms d'objets dans la base de données de destination.

        Source Objects

        Sélectionnez un ou plusieurs objets dans la section Source Objects. Cliquez sur l'icône Rightwards arrow pour ajouter les objets à la section Selected Objects.

        Remarque

        Le niveau de granularité pour la sélection des objets à migrer comprend le schéma, la table et la colonne. Si vous sélectionnez uniquement des tables ou des colonnes comme objets à migrer, les autres objets tels que les vues, les déclencheurs et les procédures stockées ne seront pas migrés vers la base de données de destination.

        Selected Objects
        Remarque

        • Si vous utilisez la fonctionnalité de mappage des noms d'objets, la migration d'autres objets dépendant de l'objet renommé risque d'échouer.

        • Pour filtrer les données à l'aide d'une clause WHERE, cliquez avec le bouton droit sur la table à migrer dans la zone Selected Objects et spécifiez la condition de filtrage dans la boîte de dialogue qui s'affiche. Pour obtenir des instructions, consultez la rubrique Définir des conditions de filtrage.

        • Pour sélectionner les opérations SQL à migrer au niveau de la base de données ou de la table, cliquez avec le bouton droit sur l'objet dans la zone Selected Objects et choisissez les opérations SQL souhaitées dans la boîte de dialogue qui s'affiche. Pour consulter la liste des opérations prises en charge, reportez-vous à la section Opérations SQL prises en charge pour la migration incrémentielle.

      2. Cliquez sur Next: Advanced Settings pour configurer les paramètres avancés.

        Paramètre

        Description

        Dedicated Cluster for Task Scheduling

        Par défaut, DTS planifie les tâches sur un cluster partagé et aucune sélection n'est requise. Vous pouvez acheter un cluster dédié avec des spécifications spécifiques pour exécuter les tâches de migration DTS. Pour plus d'informations, consultez Qu'est-ce qu'un cluster dédié DTS ?.

        Select the engine type of the destination database

        Sélectionnez le type de moteur pour la base de données de destination en fonction de vos besoins métier.

        • InnoDB : Le moteur de stockage par défaut.

        • X-Engine : Un moteur de stockage de base de données pour le traitement des transactions en ligne (OLTP).

        Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database.

        Si vous utilisez Data Management (DMS) ou gh-ost pour effectuer des modifications DDL en ligne dans la base de données source, vous pouvez choisir de migrer ou non les données issues des tables temporaires générées par ces modifications DDL en ligne.

        Important

        • Les tâches DTS ne prennent pas en charge l'utilisation d'outils tels que pt-online-schema-change pour effectuer des modifications DDL en ligne. Dans le cas contraire, la tâche DTS échoue.

        • Les méthodes de traitement pour chaque phase sont les suivantes : Les phases Schema Migration et Full Data Migration n'autorisent pas les opérations DDL qui modifient la structure de la base de données ou des tables. Par conséquent, elles ne sont pas contrôlées par la stratégie DDL en ligne.

          • Schema Migration : Non contrôlé par la stratégie DDL en ligne. Les tables temporaires associées sont créées.

          • Full Data Migration : Non contrôlé par la stratégie DDL en ligne. La migration des tables temporaires n'est pas incluse dans les objets de migration complète. Toutes les tables dont les noms correspondent à l'expression régulière (^_(.+)_(?:gho|new)$ ou ^_(.+)_(?:ghc|del|old)$) sont filtrées.

          • Incremental Data Migration : Contrôlé par la stratégie DDL en ligne.

            • Yes : Migre les modifications de données provenant des tables temporaires (par exemple, _table_name_gho) générées par les opérations DDL en ligne.

            • No, Adapt to DMS Online DDL et No, Adapt to gh-ost : Filtre les modifications de données provenant des tables temporaires (par exemple, _table_name_gho) générées par des outils tels que gh-ost, selon des règles d'expressions régulières.

        • Yes : Migre les données des tables temporaires générées par les modifications DDL en ligne.

          Remarque

          Si les modifications DDL en ligne génèrent une grande quantité de données dans les tables temporaires, cela peut entraîner une latence de la tâche.

        • No, Adapt to DMS Online DDL : Ne migre pas les données des tables temporaires générées par les modifications DDL en ligne. Seules les instructions DDL d'origine exécutées via Data Management (DMS) sont migrées.

          Remarque

          Cette option entraîne le verrouillage des tables dans la base de données de destination.

        • No, Adapt to gh-ost : Ne migre pas les données des tables temporaires générées par les modifications DDL en ligne. Cette option prend en charge des règles de filtrage personnalisées. DTS filtre les modifications de données provenant des tables temporaires (par exemple, _table_name_gho) générées par des outils tels que gh-ost, selon des règles d'expressions régulières. Vous pouvez modifier les expressions régulières par défaut utilisées pour faire correspondre les tables fantômes et inutiles selon vos besoins :

          • Table fantôme : ^_(.+)_(?:gho|new)$

          • Table inutile : ^_(.+)_(?:ghc|del|old)$

          Remarque

          Cette option entraîne le verrouillage des tables dans la base de données de destination.

        Whether to Migrate Accounts

        Choisissez si vous souhaitez migrer les informations de compte depuis la base de données source. Si vous sélectionnez Yes, vous devez également sélectionner les comptes à migrer et confirmer leurs autorisations. Pour plus d'informations, y compris les méthodes d'autorisation, consultez Migrer des comptes de base de données.

        Retry Time for Failed Connections

        Une fois la tâche de migration démarrée, si la connexion à la base de données source ou de destination échoue, DTS signale une erreur et tente immédiatement de rétablir la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser cette durée entre 10 et 1440 minutes. Nous vous recommandons de définir une durée supérieure à 30 minutes. Si DTS se reconnecte aux bases de données source et de destination dans le délai spécifié, la tâche de migration reprend automatiquement. Sinon, la tâche échoue.

        Remarque

        • Pour plusieurs instances DTS partageant la même source ou destination, la durée de nouvelle tentative réseau est déterminée par le paramètre de la dernière tâche créée.

        • Étant donné que la tâche est facturée pendant la période de nouvelle tentative de connexion, nous vous recommandons de personnaliser la durée de nouvelle tentative en fonction de vos besoins métier, ou de libérer l'instance DTS dès que possible après la libération des instances de base de données source et de destination.

        Retry Time for Other Issues

        Une fois la tâche de migration démarrée, si un problème autre qu'un problème de connectivité, tel qu'une exception d'exécution DDL ou DML, survient dans la base de données source ou de destination, DTS signale une erreur et tente immédiatement de relancer l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser cette durée entre 1 et 1440 minutes. Nous vous recommandons de définir une durée supérieure à 10 minutes. Si les opérations concernées réussissent dans le délai de nouvelle tentative spécifié, la tâche de migration reprend automatiquement. Sinon, la tâche échoue.

        Important

        La valeur de Retry Time for Other Issues doit être inférieure à la valeur de Retry Time for Failed Connections.

        Enable Throttling for Full Data Migration

        Lors de la migration complète, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui peut augmenter la charge de la base de données. Si nécessaire, vous pouvez activer la limitation de débit pour la tâche de migration complète. Vous pouvez définir les paramètres Queries per second (QPS) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s) afin de réduire la charge sur la base de données de destination.

        Remarque

        • Cet élément de configuration est disponible uniquement si vous sélectionnez Full Data Migration pour Migration Types.

        • Vous pouvez également ajuster la vitesse de migration complète une fois que l'instance de migration est en cours d'exécution.

        Enable Throttling for Incremental Data Migration

        Si nécessaire, vous pouvez également choisir de définir des limites de vitesse pour la tâche de migration incrémentielle. Vous pouvez définir les paramètres RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s) afin de réduire la charge sur la base de données de destination.

        Remarque

        • Cet élément de configuration est disponible uniquement si vous sélectionnez Incremental Data Migration pour Migration Types.

        • Vous pouvez également ajuster la vitesse de migration incrémentielle une fois que l'instance de migration est en cours d'exécution.

        Environment Tag

        Sélectionnez un tag d'environnement pour identifier l'instance en fonction de vos besoins métier. Aucune sélection n'est requise pour cet exemple.

        Whether to delete SQL operations on heartbeat tables of forward and reverse tasks

        Choisissez si vous souhaitez écrire les informations SQL de pulsation (heartbeat) dans la base de données source lorsque l'instance DTS est en cours d'exécution.

        • Yes : Les informations SQL de pulsation ne sont pas écrites dans la base de données source. Cela peut entraîner un retard signalé par l'instance DTS.

        • No : Écrit les informations SQL de pulsation dans la base de données source. Cela peut interférer avec des fonctionnalités telles que la sauvegarde physique et le clonage de la base de données source.

        Configure ETL

        Choisissez si vous souhaitez activer la fonctionnalité Extract, Transform, Load (ETL). Pour plus d'informations, consultez Qu'est-ce que l'ETL ? Valeurs valides :

        Monitoring and Alerting

        Sélectionnez si vous souhaitez configurer des alertes et recevoir des notifications d'alerte en fonction de vos besoins métier.

        • No : Ne configure pas d'alerte.

        • Yes : Configurez les alertes en définissant un seuil d'alerte et des notifications d'alerte. En cas d'échec de la migration ou si la latence dépasse le seuil, le système envoie une notification d'alerte.

      3. Cliquez sur Next: Data Validation pour configurer une tâche de validation des données.

        Si vous souhaitez utiliser la fonctionnalité de validation des données, consultez Configurer la validation des données pour obtenir les instructions de configuration.

    7. Enregistrez la tâche et exécutez une pré-vérification.

      • Pour afficher les paramètres de configuration de cette instance lors de l'appel de l'opération API, placez le pointeur sur le bouton Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters dans la bulle qui s'affiche.

      • Si vous n'avez pas besoin d'afficher les paramètres API ou si vous avez terminé leur consultation, cliquez sur Next: Save Task Settings and Precheck en bas de la page.

      Remarque

      • Avant le démarrage de la tâche de migration, DTS effectue une pré-vérification. La tâche ne démarre qu'après avoir réussi cette pré-vérification.

      • Si la pré-vérification échoue, cliquez sur View Details à côté de l'élément de vérification ayant échoué, corrigez le problème selon les instructions, puis relancez la pré-vérification.

      • Si un avertissement est signalé lors de la pré-vérification :

        • Pour les éléments de vérification qui ne peuvent pas être ignorés, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème selon les instructions, puis relancez la pré-vérification.

        • Pour les éléments de vérification qui peuvent être ignorés, vous pouvez cliquer sur Confirm Alert Details, Ignore, OK, puis Precheck Again pour ignorer l'élément d'avertissement et relancer la pré-vérification. Si vous choisissez d'ignorer un avertissement, cela peut entraîner des problèmes tels que l'incohérence des données et présenter des risques pour votre activité.

    8. Lorsque le Success Rate est de 100 %, cliquez sur Next: Purchase Instance.

    9. Achetez l'instance.

      1. Sur la page Purchase, sélectionnez la spécification de lien pour l'instance de migration des données. Pour plus d'informations, consultez le tableau suivant.

        Catégorie

        Paramètre

        Description

        New Instance Class

        Resource Group Settings

        Sélectionnez le groupe de ressources auquel l'instance appartient. La valeur par défaut est le groupe de ressources par défaut. Pour plus d'informations, consultez Qu'est-ce que Resource Management ?

        Instance Class

        DTS propose des spécifications de migration offrant différents niveaux de performance. La spécification du lien influence la vitesse de migration. Choisissez une spécification adaptée à votre scénario métier. Pour plus d'informations, consultez Spécifications des liens de migration des données.

      2. Une fois la configuration terminée, lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.

      3. Cliquez sur Buy and Start. Dans la boîte de dialogue OK qui s'affiche, cliquez sur OK.

        Vous pouvez suivre la progression de la tâche de migration sur la page de liste Data Migration Tasks.

        Remarque

        • Si la tâche de migration n'inclut pas de migration incrémentielle, elle s'arrête automatiquement une fois la migration complète terminée. Une fois la tâche arrêtée, son Status passe à Completed.

        • Si la tâche de migration inclut une migration incrémentielle, elle ne s'arrête pas automatiquement. La tâche de migration incrémentielle continue de s'exécuter. Pendant l'exécution de cette tâche, le Status de la tâche est Running.