Tous les produits
Search

Ce produit

    Data Transmission Service:Migrer une base de données MySQL auto-gérée vers ApsaraDB RDS for MySQL

    Centre de documentation

    Data Transmission Service:Migrer une base de données MySQL auto-gérée vers ApsaraDB RDS for MySQL

    Dernière mise à jour :Aug 10, 2026

    Data Transmission Service (DTS) migre les données d'une base de données MySQL sur site, sur une instance ECS ou sur une plateforme cloud tierce vers une instance ApsaraDB RDS for MySQL sans interruption de service. DTS prend en charge la migration du schéma, la migration complète des données et la migration incrémentielle des données. Combinez ces types pour effectuer la migration sans interrompre vos applications.

    Prérequis

    • Votre base de données MySQL auto-gérée est connectée à Alibaba Cloud et les blocs CIDR des serveurs DTS ont été ajoutés aux paramètres de sécurité de la base (groupes de sécurité, pare-feu ou listes d'autorisation). Consultez la rubrique Préparatifs.

      Remarque

      Versions prises en charge : consultez la rubrique Solutions de migration.

    • Si vous avez besoin d'une migration incrémentielle des données, activez la journalisation binaire sur votre base de données MySQL auto-gérée. Consultez la rubrique Créer un compte pour une base MySQL auto-gérée et configurer son journal binaire.

    • Une instance ApsaraDB RDS for MySQL de destination a été créée avec une capacité de stockage supérieure à celle utilisée par la base source. Consultez la rubrique Créer une instance ApsaraDB RDS for MySQL.

    Précautions

    Remarque

    • DTS migre les clés étrangères lors de la migration du schéma.

    • Pendant la migration complète et incrémentielle des données, DTS désactive temporairement les vérifications de contraintes et les cascades de clés étrangères au niveau de la session. Les mises à jour ou suppressions en cascade sur la base source pendant l'exécution de la tâche peuvent entraîner des incohérences de données.

    Type

    Description

    Limites de la base source

    • Exigence de bande passante : le serveur hébergeant la base source doit disposer d'une bande passante sortante suffisante. Sinon, la vitesse de migration diminuera.

    • Chaque table à migrer doit posséder une clé primaire ou une contrainte UNIQUE, et les colonnes de clé doivent contenir des valeurs uniques. Sinon, des doublons peuvent apparaître dans la base de destination.

    • Si vous sélectionnez des tables comme objets de migration et que vous les modifiez (par exemple, en mappant les noms de colonnes), une seule tâche de migration prend en charge jusqu'à 1 000 tables. Si vous dépassez cette limite, la tâche échouera avec une erreur lors de la soumission. Pour résoudre ce problème, répartissez les tables sur plusieurs tâches ou configurez une tâche de migration de base entière.

    • Si vous avez besoin d'une migration incrémentielle, activez la journalisation binaire :

      • Définissez binlog_format sur ROW et binlog_row_image sur FULL. Sinon, la pré-vérification échouera et la tâche ne pourra pas démarrer.

        Important

        Si votre source MySQL auto-gérée est un cluster maître-maître (chaque instance agissant à la fois comme maître et esclave), activez le paramètre log_slave_updates. Cela garantit que DTS peut lire tous les journaux binaires.

      • Pour les instances RDS for MySQL, conservez les journaux binaires locaux pendant au moins trois jours (sept jours recommandés). Pour les bases de données MySQL auto-gérées, conservez les journaux binaires locaux pendant au moins sept jours. Si DTS ne peut pas accéder aux journaux binaires, la tâche échoue. Dans des cas extrêmes, des incohérences ou des pertes de données peuvent survenir. Les problèmes causés par des périodes de rétention des journaux binaires inférieures aux exigences de DTS ne sont pas couverts par le SLA de DTS.

        Remarque

        Pour définir la retention period des journaux binaires locaux sur une instance RDS for MySQL, consultez la rubrique Supprimer automatiquement les journaux locaux.

    • Opérations non autorisées sur la base source :

      • N'exécutez pas d'opérations DDL modifiant les schémas de base ou de table pendant la migration du schéma ou la migration complète. Sinon, la tâche de migration échouera.

        Remarque

        Pendant la migration complète, DTS interroge la base source. Cela crée des verrous de métadonnées qui peuvent bloquer les opérations DDL sur la base source.

      • Si vous n'effectuez qu'une migration complète, n'écrivez pas de nouvelles données dans l'instance source. Sinon, les données source et destination deviendront incohérentes. Pour maintenir la cohérence des données en temps réel, sélectionnez la migration du schéma, la migration complète et la migration incrémentielle.

    • DTS ne migre pas les données générées par des modifications qui n'écrivent pas dans les journaux binaires. Par exemple, les données restaurées à partir de sauvegardes physiques ou créées par des opérations en cascade.

      Remarque

      Si cela se produit, relancez la migration complète lorsque votre activité le permet.

    • Si votre base MySQL source est en version 8.0.23 ou ultérieure et contient des colonnes cachées invisibles, DTS ne peut pas lire ces colonnes. Cela peut entraîner une perte de données.

      Remarque

      Exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour rendre la colonne cachée visible. Pour plus d'informations, consultez Colonnes invisibles.

    • Compatibilité MySQL : Lorsque DTS migre des données depuis une base source de la famille MySQL, il s'appuie sur le protocole MySQL standard et le format Binlog. Les comportements incompatibles avec MySQL standard ne sont pas pris en charge. Si votre base source prétend être compatible avec MySQL mais se comporte différemment (par exemple, lorsqu'OceanBase est connecté en tant que source en mode MySQL, l'horodatage du dernier événement rotate dans le Binlog est 0, ce qui diffère de MySQL), la tâche de migration DTS peut échouer.

    Autres limites

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

    • Si votre base source utilise des opérations DDL en ligne en mode table temporaire (y compris les scénarios de fusion multi-tables) ou ajoute des index basés sur des fonctions aux colonnes de clé unique, des pertes de données ou des échecs de tâche peuvent survenir sur la base de destination.

    • DTS ne prend pas en charge la migration des analyseurs définis à l'aide de la syntaxe de commentaire.

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

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

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

        • Pendant la migration incrémentielle, DTS ne conserve pas l'enregistrement dans la base de destination. L'enregistrement de la base source écrase celui de la base 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. Agissez avec prudence.

    • Si votre base MySQL de destination est en version 8.0.23 ou ultérieure et que la colonne cible est une colonne cachée invisible, DTS ne peut pas y écrire de données. Cela peut entraîner un échec de la tâche ou une perte de données.

      Remarque

      Exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour rendre la colonne cachée visible. Pour plus d'informations, consultez Colonnes invisibles.

    • Si vous n'utilisez pas DTS pour migrer les schémas, vérifiez vous-même la compatibilité des champs. Sinon, la tâche peut échouer ou des données peuvent être perdues. Par exemple, si le type de colonne source est text et que le type de colonne de destination est varchar(255), les champs volumineux de la source peuvent être tronqués.

    • Si vos données incluent des caractères sur quatre octets (tels que des caractères chinois rares ou des emojis), la base et la table de destination doivent utiliser le jeu de caractères utf8mb4.

      Remarque

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

    • Avant la migration, évaluez les performances des bases source et destination. Exécutez la migration pendant les heures creuses. Sinon, la migration complète consommera des ressources de lecture et d'écriture sur les deux bases et augmentera leur charge.

    • La migration complète exécute des opérations INSERT simultanément. Cela fragmente les tables de destination. Après la migration complète, les tables de destination nécessitent plus d'espace de stockage que les tables source.

    • Vérifiez que la précision de migration DTS pour les colonnes FLOAT ou DOUBLE répond à vos besoins métier. DTS lit ces colonnes en utilisant ROUND(COLUMN,PRECISION). Si aucune précision n'est définie, DTS utilise 38 chiffres pour FLOAT et 308 chiffres pour DOUBLE.

    • DTS tente de récupérer les tâches ayant échoué dans un délai de sept jours. Avant de basculer le trafic vers l'instance de destination, terminez ou libérez la tâche. Ou exécutez la commande revoke pour supprimer l'autorisation d'écriture de DTS sur le compte de l'instance de destination. Cela empêche la récupération automatique d'écraser les données de destination avec celles de la source.

    • Si les écritures DDL échouent sur la base de destination, la tâche DTS continue de s'exécuter. Vérifiez les instructions DDL ayant échoué dans les journaux de la tâche. Pour plus d'informations, consultez la rubrique Afficher les journaux de tâche.

    • Si vous écrivez des colonnes portant des noms identiques mais avec une casse différente dans la même table de la base MySQL de destination, des résultats inattendus peuvent survenir. Les noms de colonnes MySQL ne sont pas sensibles à la casse.

    • Une fois la migration terminée (le statut de la tâche est Status et passe à Completed), exécutez analyze table <table_name> pour confirmer que toutes les données ont été écrites dans la table de destination. Par exemple, après un basculement de haute disponibilité (HA) dans la base MySQL de destination, les données peuvent rester en mémoire et ne jamais atteindre le disque, entraînant une perte de données.

    • Si votre instance RDS for MySQL a Always-Encrypted activé, la migration complète n'est pas prise en charge.

      Remarque

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

    • Pour migrer les comptes de base de données depuis la source, respectez les prérequis requis et examinez les considérations associées. Pour plus d'informations, consultez la rubrique Migrer les comptes de base de données.

    • En cas d'échec d'une tâche, l'équipe support de DTS tentera de la restaurer dans un délai de huit heures. Lors de la restauration, ils peuvent redémarrer la tâche ou ajuster ses paramètres.

      Remarque

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

    Cas particuliers

    • Pour les sources MySQL auto-gérées :

      • Un basculement maître-esclave sur la base source entraîne l'échec de la tâche de migration.

      • DTS calcule la latence en comparant l'horodatage du dernier enregistrement migré vers la base de destination avec l'heure actuelle. Si aucune opération DML n'est exécutée sur la source pendant une longue période, le rapport de latence devient imprécis. Si la latence semble trop élevée, exécutez une opération DML sur la source pour mettre à jour la valeur de latence.

        Remarque

        Si vous sélectionnez la migration de base entière, créez une table heartbeat. Mettez-la à jour ou écrivez-y chaque seconde.

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

      • Si votre source est Amazon Aurora MySQL ou une autre instance MySQL en cluster, assurez-vous que le nom de domaine ou l'adresse IP configuré pour la tâche (et sa résolution DNS) pointe toujours vers un nœud en lecture-écriture (RW). Sinon, la tâche de migration peut échouer.

    • Pour les sources RDS for MySQL :

      • Si vous avez besoin d'une migration incrémentielle, les instances RDS for MySQL qui n'enregistrent pas les journaux de transactions (comme les instances en lecture seule RDS for MySQL 5.6) ne sont pas prises en charge en tant que sources.

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

    • Pour les destinations RDS for MySQL :

      DTS crée automatiquement des bases de données dans RDS for MySQL. Si le nom de la base de données n'est pas conforme aux règles de nommage de RDS for MySQL, créez la base manuellement avant de configurer la tâche de migration. Pour plus d'informations, consultez la rubrique Gérer les bases de données.

    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.

    Lorsque le paramètre Access Method de la base de destination est défini sur Public IP Address, des frais de trafic Internet vous sont facturés. Pour plus d'informations, consultez la rubrique Vue d'ensemble de la facturation.

    Migration incrémentielle des données

    Facturé. Pour plus d'informations, consultez la rubrique Vue d'ensemble de la facturation.

    Types de migration

    • Migration du schéma

      Data Transmission Service (DTS) migre les définitions de schéma des objets de migration de la base source vers la base de destination.

      • DTS prend en charge la migration du 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 du schéma, DTS change le DEFINER en INVOKER pour les vues, procédures stockées et fonctions à migrer. Cette action change la valeur de SQL SECURITY en INVOKER. DTS définit également le DEFINER sur le compte de la base de destination utilisé pour la tâche de migration.

        Remarque

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

      • DTS ne migre pas les informations de compte et d'autorisation (informations USER) de la base source. DTS change également la méthode d'authentification de sécurité des vues, procédures stockées et fonctions à migrer en INVOKER. Par conséquent, lorsque vous appelez ces objets dans la base de destination, l'invoker doit disposer des autorisations de lecture et d'écriture sur la base de destination. Sinon, l'appel échoue en raison d'autorisations insuffisantes. Si le compte invoker dispose déjà des autorisations de lecture et d'écriture sur la base de destination, l'appel de ces objets n'est pas affecté. Si vous souhaitez que le DEFINER d'un objet dans la base de destination soit identique à celui de la base source, supprimez l'objet dont l'appel a échoué dans la base de destination et recréez-le. Lors de la recréation de l'objet, spécifiez le DEFINER d'origine dans l'instruction de création et assurez-vous que le compte definer existe dans la base de destination.

    • Migration complète

      DTS migre toutes les données historiques des objets de migration spécifiés de la base source vers la base de destination.

    • Migration incrémentielle

      Une fois la migration complète terminée, DTS migre les mises à jour incrémentielles des données de la base source vers la base de destination. La migration incrémentielle vous permet de migrer les données en douceur sans interrompre vos applications auto-gé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 provoquer des incohérences de données. Par exemple, si vous ne sélectionnez qu'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 destination. Pour éviter ce problème, sélectionnez la base 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 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 du schéma

    Migration complète

    Migration incrémentielle

    Base de données MySQL auto-gérée

    Autorisation SELECT

    Autorisation SELECT

    • Autorisation SELECT sur les objets à migrer.

    • Autorisations REPLICATION CLIENT, REPLICATION SLAVE et SHOW VIEW.

    • Autorisation CREATE, qui permet à DTS de créer une base de données nommée test pour faire avancer la position du journal binaire.

    Instance ApsaraDB RDS for MySQL

    Autorisations de lecture et d'écriture

    Pour créer et autoriser un compte de base de données :

    Remarque

    Pour migrer les informations de compte, le compte de la tâche de migration nécessite des autorisations supplémentaires. Consultez la rubrique Migrer les comptes de base de données.

    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 console Data Transmission Service (DTS).

      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 les rubriques Console en mode simple et Personnaliser la disposition et le style de la console DMS.

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

      2. Dans la barre de menu supérieure, choisissez Data + 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. Configurez les bases de données source et de destination.

      Avertissement

      Après avoir sélectionné les instances source et de destination, nous vous recommandons de lire attentivement les limites affichées en haut de la page. Sinon, la tâche peut échouer ou des incohérences de données peuvent survenir.

      Section

      Paramètre

      Description

      Non applicable

      Task Name

      DTS génère automatiquement un nom de tâche. Nous vous recommandons de spécifier un nom descriptif pour une identification facile. Le nom n'a pas besoin d'être unique.

      Source Database

      Select Existing Connection

      Aucune connexion existante n'est nécessaire. Configurez les informations de la base ci-dessous.

      Database Type

      Sélectionnez MySQL.

      Access Method

      Sélectionnez une méthode d'accès pour votre base source. Cet exemple utilise Public IP Address.

      Remarque

      Si votre base source est auto-gérée, vous devez également effectuer les préparatifs requis.

      Instance Region

      Sélectionnez la région de la base MySQL source.

      Domain Name or IP

      Saisissez le point de terminaison de la base MySQL source. Cet exemple utilise un point de terminaison public.

      Port Number

      Saisissez le port de service de la base MySQL source. Le port doit être accessible via Internet. Par défaut : 3306.

      Database Account

      Saisissez le compte de la base MySQL source. Autorisations requises : Autorisations requises pour les comptes de base de données.

      Database Password

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

      Encryption

      Sélectionnez Non-encrypted ou SSL-encrypted selon vos besoins.

      • Si le chiffrement SSL n'est pas activé pour la base MySQL auto-gérée, sélectionnez Non-encrypted.

      • Si le chiffrement SSL est activé pour la base MySQL auto-gérée, sélectionnez SSL-encrypted. Vous devez également télécharger un CA Certificate et saisir le CA Certificate Password.

      Destination Database

      Select Existing Connection

      Aucune connexion existante n'est nécessaire. Configurez les informations de la base ci-dessous.

      Database Type

      Sélectionnez MySQL.

      Access Method

      Sélectionnez Alibaba Cloud Instance.

      Instance Region

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

      Replicate Data Across Alibaba Cloud Accounts

      Cet exemple utilise le même compte Alibaba Cloud. Sélectionnez No.

      RDS Instance ID

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

      Database Account

      Saisissez le compte de la base de l'instance ApsaraDB RDS for MySQL de destination. Autorisations requises : Autorisations requises pour les comptes de base de données.

      Database Password

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

      Encryption

      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 la rubrique Activer rapidement le chiffrement SSL à l'aide d'un certificat cloud.

    4. Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page. Dans la boîte de dialogue CIDR Blocks of DTS Servers qui s'affiche, cliquez sur Test Connectivity.

      Remarque

      Assurez-vous que les plages d'adresses IP du service DTS sont ajoutées automatiquement ou manuellement aux paramètres de sécurité des bases source et de destination pour autoriser l'accès depuis les serveurs DTS. Pour plus d'informations, consultez la rubrique Ajouter les adresses IP des serveurs DTS à une liste d'autorisation.

    5. Configurez les objets de la tâche.

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

        Paramètre

        Description

        Migration Types

        • Si vous n'avez besoin que d'une migration complète, sélectionnez à la fois Schema Migration et Full Data Migration.

        • Pour effectuer 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, vous devez vous assurer qu'une base et des tables destinées à recevoir les données existent dans la base de destination. Vous pouvez également utiliser la fonctionnalité de mappage de nom d'objet dans la zone Selected Objects selon vos besoins.

        • Si vous ne sélectionnez pas Incremental Data Migration, n'écrivez pas de nouvelles données dans l'instance source pendant la migration des données 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. Ignorez si aucun déclencheur n'est concerné. Consultez la rubrique Configurer une méthode pour synchroniser ou migrer les déclencheurs.

        Remarque

        Ce paramètre n'est disponible que si vous sélectionnez à la fois Migration Types et Incremental Data Migration pour Schema Migration.

        Enable Migration Assessment

        Évalue si les schémas source et de destination (longueur d'index, procédures stockées, tables dépendantes) répondent aux exigences. Sélectionnez Yes ou No selon vos besoins.

        Remarque

        • Vous ne pouvez configurer ce paramètre que si vous sélectionnez Schema Migration pour Migration Types.

        • Si vous sélectionnez Yes, la pré-vérification peut prendre plus de temps. Vous pouvez afficher le Assessment Result pendant la pré-vérification. Le résultat de l'évaluation n'affecte pas le résultat de la pré-vérification.

        Processing Mode of Conflicting Tables

        • Precheck and Report Errors : Vérifie si des tables portant les mêmes noms existent dans la base de destination. Si aucune table portant les mêmes noms n'existe, la pré-vérification réussit. Si des tables portant les mêmes noms existent, une erreur est signalée lors de la pré-vérification et la tâche de migration des données ne démarre pas.

          Remarque

          Si une table de la base de destination porte le même nom mais ne peut pas être facilement supprimée ou renommée, vous pouvez modifier le nom de la table dans la base de destination. Pour plus d'informations, consultez la rubrique Mappage de nom d'objet.

        • Ignore Errors and Proceed : Ignore la vérification des tables portant les mêmes noms.

          Avertissement

          La sélection de Ignore Errors and Proceed peut entraîner des incohérences de données et des risques métier. Par exemple :

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

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

            • Pendant la migration incrémentielle, DTS ne conserve pas l'enregistrement dans la base de destination. L'enregistrement de la base source écrase celui de la base 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. Agissez avec prudence.

        Whether to migrate Event

        Indiquez si vous souhaitez migrer les événements de la base source. Si vous sélectionnez Yes, des étapes supplémentaires sont requises. Consultez la rubrique Synchroniser ou migrer les é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, tables, colonnes, etc.) dans l'instance de destination. Par défaut, DTS default policy est sélectionné. Vous pouvez également choisir de conserver la sensibilité à la casse cohérente avec la politique par défaut de la base source ou de destination. Pour plus d'informations, consultez la rubrique Sensibilité à la casse des noms d'objets dans la base de destination.

        Source Objects

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

        Remarque

        La granularité de sélection des objets de migration est la base, la table et la colonne. Si vous ne sélectionnez que des tables ou des colonnes comme objets de migration, les autres objets tels que les vues, les déclencheurs et les procédures stockées ne sont pas migrés vers la base de destination.

        Selected Objects
        Remarque

        • Le mappage de nom d'objet peut entraîner l'échec des migrations d'objets dépendants.

        • Pour filtrer les données par une condition WHERE, faites un clic droit sur la table dans la section Selected Objects et configurez la condition. Consultez la rubrique Filtrer les données à migrer.

        • Pour sélectionner les opérations SQL à migrer au niveau de la base ou de la table, faites un clic droit sur l'objet dans la section Selected Objects et choisissez les opérations dans la boîte de dialogue.

      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é. Vous n'avez pas besoin d'en sélectionner un. Si vous souhaitez des tâches plus stables, vous pouvez acheter un cluster dédié pour exécuter les tâches de migration DTS.

        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 source, vous pouvez choisir de migrer ou non les données des tables temporaires générées par les 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. Sinon, 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 modifiant la structure de la base ou de la table. 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 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 des tables temporaires (par exemple, _table_name_gho) générées par des outils tels que gh-ost selon des règles d'expression régulière.

        • 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. Il ne migre que les instructions DDL d'origine exécutées à l'aide de Data Management (DMS).

          Remarque

          Cette option provoque le verrouillage des tables dans la base 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. Il prend en charge des règles de filtrage personnalisées. DTS filtre les modifications de données des tables temporaires (par exemple, _table_name_gho) générées par des outils tels que gh-ost selon des règles d'expression régulière. 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 provoque le verrouillage des tables dans la base de destination.

        Whether to Migrate Accounts

        Indiquez si vous souhaitez migrer les comptes de la base source. Si vous sélectionnez Yes, sélectionnez les comptes à migrer et confirmez leurs autorisations.

        Retry Time for Failed Connections

        Après le démarrage de la tâche de migration, si la connexion à la base source ou de destination échoue, DTS signale une erreur et commence immédiatement à retenter la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser la durée de nouvelle tentative à une valeur comprise entre 10 et 1440 minutes. Nous vous recommandons de définir la durée à plus de 30 minutes. Si DTS se reconnecte aux bases source et de destination dans la durée spécifiée, 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.

        • Comme la tâche vous 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 source et de destination.

        Retry Time for Other Issues

        Après le démarrage de la tâche de migration, si un problème autre que la connectivité (tel qu'une exception d'exécution DDL ou DML) survient dans la base source ou de destination, DTS signale une erreur et commence immédiatement à retenter l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser la durée de nouvelle tentative à une valeur comprise entre 1 et 1440 minutes. Nous vous recommandons de définir la durée à plus de 10 minutes. Si les opérations associées réussissent dans la durée de nouvelle tentative spécifiée, 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

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

        Remarque

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

        • Vous pouvez également ajuster la vitesse de migration complète après le démarrage de l'instance de migration.

        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 RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s) pour réduire la charge sur la base de destination.

        Remarque

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

        • Vous pouvez également ajuster la vitesse de migration incrémentielle après le démarrage de l'instance de migration.

        Environment Tag

        Tag d'environnement facultatif pour identifier l'instance. Non requis pour cet exemple.

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

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

        • Yes : Les informations SQL heartbeat ne sont pas écrites dans la base source. Cela peut amener l'instance DTS à signaler un retard.

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

        Configure ETL

        Selon vos besoins métier, indiquez si vous souhaitez configurer la fonctionnalité ETL pour traiter les données.

        Monitoring and Alerting

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

        • No : Ne définit pas d'alerte.

        • Yes : Configurez les alertes en définissant un seuil d'alerte et un notifications d'alerte. Si une migration échoue 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.

        Pour plus d'informations sur la fonctionnalité de validation des données, consultez la rubrique Configurer la validation des données.

    6. 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 ou avez terminé d'afficher les paramètres API, 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 la 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 l'invite, 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 l'invite, 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 des incohérences de données et présenter des risques pour votre activité.

    7. Achetez l'instance.

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

      2. Sur la page Purchase, sélectionnez la spécification de liaison pour l'instance de migration de 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 la rubrique Qu'est-ce que Resource Management ?

        Instance Class

        DTS propose des spécifications de migration avec différents niveaux de performance. La spécification de liaison affecte la vitesse de migration. Vous pouvez sélectionner une spécification en fonction de votre scénario métier. Pour plus d'informations, consultez la rubrique Spécifications de liaison de migration de données.

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

      4. Cliquez sur Buy and Start, puis cliquez sur OK dans la boîte de dialogue OK.

        Affichez la progression de la tâche sur la page 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 la tâche de migration incrémentielle, le Status de la tâche est Running.

        • Pour basculer les charges de travail, effectuez l'opération pendant les heures creuses lorsque la latence de migration est faible ou nulle. Consultez la rubrique Basculer les charges de travail.

    FAQ

    Q : Une fois qu'une instance est en cours d'exécution, puis-je modifier Whether to delete SQL operations on heartbeat tables of forward and reverse tasks ?

    R : Non.