Tous les produits
Search

Ce produit

    Data Transmission Service:Migrer RDS MySQL vers PolarDB-X 2,0

    Centre de documentation

    Data Transmission Service:Migrer RDS MySQL vers PolarDB-X 2,0

    Dernière mise à jour :Sep 23, 2026

    Migrez les données d'une instance ApsaraDB RDS for MySQL vers une instance PolarDB-X à l'aide du service Data Transmission Service (DTS).

    Bases de données source prises en charge

    Les types de bases de données MySQL source suivants peuvent être migrés vers une instance PolarDB-X 2,0. Cette rubrique utilise une instance ApsaraDB RDS for MySQL comme exemple. La procédure est similaire pour les autres bases de données source.

    • Une instance ApsaraDB RDS for MySQL.

    • Les types de bases de données auto-gérées suivants :

      • 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

    • Vous avez créé une instance PolarDB-X 2,0.

    • L'instance PolarDB-X 2,0 doit disposer d'un espace de stockage supérieur à celui utilisé par l'instance ApsaraDB RDS for MySQL.

    Limitations

    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 de données source pendant l'exécution de la tâche peuvent entraîner une incohérence des données.

    Type

    Description

    Limites de la base de données source

    • Exigence en matière de bande passante : le serveur hébergeant la base de données 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 enregistrements en double peuvent apparaître dans la base de données 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 échoue 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 de données complète.

    • 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 échoue et la tâche ne peut pas démarrer.

        Important

        Si votre source MySQL auto-gérée est un cluster maître-maître, où chaque instance agit à 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, une incohérence ou une perte de données peut survenir. Les problèmes causés par des périodes de rétention des journaux binaires inférieures à celles requises par 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 Supprimer automatiquement les journaux locaux.

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

      • N'exécutez pas d'opérations DDL qui modifient les schémas de base de données ou de tables pendant la migration complète. Sinon, la tâche de migration échouera.

        Remarque

        Pendant la migration complète, DTS interroge la base de données source. Cela crée des verrous de métadonnées qui peuvent bloquer les opérations DDL sur la base de données 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 de destination deviendront incohérentes. Pour maintenir la cohérence des données en temps réel, sélectionnez 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. Cela inclut 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 de données source MySQL 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 de données source de la famille MySQL, il s'appuie sur le protocole MySQL standard et le format Binlog, et les comportements incompatibles 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 de MySQL (par exemple, lorsqu'OceanBase est connecté comme source en mode MySQL, l'horodatage de l'événement de rotation final dans le Binlog est 0, ce qui diffère de MySQL), la tâche de migration DTS peut échouer.

    Autres limites

    • Si un conflit de clé primaire ou de clé unique survient pendant la migration :

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

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

        • Pendant la migration incrémentielle, DTS ne conserve pas l'enregistrement dans la base de données de destination. L'enregistrement 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.

    • Si votre base de données 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, une perte de données ou un échec de la tâche peut survenir sur la base de données de destination.

    • Avant la migration, évaluez les performances des bases de données source et de destination. Exécutez la migration pendant les heures creuses de votre activité. Sinon, la migration complète consomme des ressources de lecture et d'écriture sur les deux bases de données et augmente la charge de la base de données.

    • La migration complète exécute des opérations INSERT de manière concurrente. 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 les données source.

    • 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 de schéma, la migration complète et la migration incrémentielle.

    • Si une tâche échoue, le support DTS tentera de la restaurer dans un délai de huit heures. Pendant la restauration, ils peuvent redémarrer la tâche ou ajuster ses paramètres.

      Remarque

      Seuls les paramètres de tâche DTS sont modifiés, pas les paramètres de base de données. Les paramètres qui peuvent être ajustés incluent ceux répertoriés dans Modifier les paramètres de l'instance.

    • Si la table PolarDB-X 2,0 de destination a le partitionnement automatique activé (auto_partition=true), chaque instruction DDL exécutée sur la source ne peut contenir qu'une seule alter_specification. Sinon, DTS signale une erreur (TDDL-4998 : Multi alter specifications when create GSI not support yet). Pour exécuter une instruction DDL contenant plusieurs éléments alter_specification, divisez chaque alter_specification en une instruction DDL distincte et exécutez-les une par une. Pour plus d'informations, consultez ALTER TABLE (mode DRDS) et ALTER TABLE (mode AUTO).

    Cas particuliers

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

      • Un basculement maître-esclave sur la base de données 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 données 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 de données complète, créez une table de heartbeat. Mettez-la à jour ou écrivez-y chaque seconde.

      • DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS test sur la base de données 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, ainsi que sa résolution DNS, pointent 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, telles que les instances en lecture seule RDS for MySQL 5.6, ne sont pas prises en charge comme sources.

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

    Facturation

    Type de migration

    Frais de configuration de l'instance

    Frais de trafic Internet

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

    Gratuit.

    Lorsque le paramètre Access Method de la base de données de destination est défini sur Public IP Address, vous êtes facturé pour le trafic Internet. Pour plus d'informations, consultez Présentation de la facturation.

    Migration incrémentielle des données

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

    Types de migration

    • Migration de schéma

      Data Transmission Service (DTS) migre les définitions de schéma des objets de migration de 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.

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

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

    • Migration complète

      DTS migre toutes les données historiques des objets de migration spécifiés de 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 mises à jour incrémentielles des données de la base de données source vers la base de données de destination. La migration incrémentielle vous permet de migrer les données en toute transparence sans interrompre vos applications auto-gérées.

    Opérations SQL prises en charge pour la migration incrémentielle

    Type

    Instruction SQL

    DML

    INSERT, UPDATE et DELETE

    DDL

    • ALTER TABLE et ALTER VIEW

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

    • DROP INDEX et DROP TABLE

    • RENAME TABLE

      Important

      Une opération RENAME TABLE peut provoquer une incohérence des données. Par exemple, si vous sélectionnez une seule table comme objet de migration et que vous renommez la table dans l'instance source pendant la migration, les données de cette table ne sont 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 appartient la table 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 appartient la table avant et après l'opération RENAME TABLE sont toutes deux incluses dans les objets de migration.

    • TRUNCATE TABLE

    Autorisations des 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-X instance

    autorizations de lecture et d'écriture

    Pour créer et autoriser des comptes de base de données, consultez :

    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 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 Migration > Data + AI > Data Transmission (DTS).

      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 pourrait échouer ou entraîner une incohérence des données.

      Catégorie

      Paramètre

      Description

      N/A

      Data Migration

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

      Source Database

      Create Task

      • Pour utiliser une instance de base de données qui a été ajoutée au système (créée ou enregistrée), sélectionnez l'instance de base de données souhaitée dans la liste déroulante. Les informations de base de données ci-dessous seront configurées automatiquement.

        Remarque

        Dans la console DMS, ce paramètre est nommé Task Name.

      • Si vous n'avez pas enregistré l'instance de base de données auprès du système, ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de base de données ci-dessous.

      Database Type

      Sélectionnez Select Existing Connection.

      Access Method

      Sélectionnez Alibaba Cloud Instance.

      MySQL

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

      Cross-account

      Dans cet exemple, la migration s'effectue au sein du même compte Alibaba Cloud. Sélectionnez No.

      Instance Region

      Sélectionnez 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 plus d'informations sur les exigences en matière d'autorisations, consultez Exigences en matière d'autorisations pour les comptes de base de données.

      Database Password

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

      RDS Instance ID

      Sélectionnez Non-encrypted ou SSL-encrypted en fonction des exigences de votre base de données. Si vous définissez ce paramètre sur Connection Method, 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 Existing Connection

      • Pour utiliser une instance de base de données qui a été ajoutée au système (créée ou enregistrée), sélectionnez l'instance de base de données souhaitée dans la liste déroulante. Les informations de base de données ci-dessous seront configurées automatiquement.

        Remarque

        Dans la console DMS, ce paramètre est nommé Select a DMS database instance..

      • Si vous n'avez pas enregistré l'instance de base de données auprès du système, ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de base de données ci-dessous.

      Database Type

      Sélectionnez PolarDB-X 2.0.

      Select a DMS database instance.

      Sélectionnez Alibaba Cloud Instance.

      Instance Region

      Sélectionnez la région où réside l'instance PolarDB-X 2,0 de destination.

      Access Method

      Sélectionnez l'instance PolarDB-X 2,0 de destination.

      Database Account

      Saisissez le compte de base de données de l'instance PolarDB-X 2,0 de destination. Pour plus d'informations sur les exigences en matière d'autorisations, consultez Exigences en matière d'autorisations pour les comptes de base de données.

      Database Password

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

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

      Remarque

      • Assurez-vous que le segment d'adresses IP du service DTS est ajouté automatiquement ou manuellement aux paramètres de sécurité des bases de données source et de destination afin d'autoriser l'accès depuis les serveurs DTS. Pour plus d'informations, consultez Ajouter des adresses IP de serveur DTS à une liste d'autorisation.

      • Si la base de données source ou de destination est une base de données auto-gérée (le paramètre Access Method n'est pas Alibaba Cloud Instance), vous devez également cliquer sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers qui s'affiche.

    5. Configurez les objets de la tâche.

      1. Sur la page Instance ID, 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 Test Connectivity and Proceed.

        • Pour réaliser une migration sans interruption de service, sélectionnez Access Method, Alibaba Cloud Instance et Test Connectivity.

        Remarque

        • Si vous ne sélectionnez pas CIDR Blocks of DTS Servers, assurez-vous qu'une base de données et des tables destinées à recevoir les données existent dans la base de données cible. Vous pouvez également utiliser la fonctionnalité de mappage des noms d'objets dans la zone Configure 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.

        Processing Mode for Existing Destination Tables

        • Full Data Migration : vérifie si des tables portant le même nom existent dans la base de données cible. Si aucune table homonyme n'existe, la prévérification est validée. En cas de tables homonymes, une erreur est signalée lors de la prévérification et la tâche de migration de données ne démarre pas.

          Remarque

          Si une table de la base de données cible porte le même nom mais ne peut pas être facilement supprimée ou renommée, vous pouvez modifier le nom de cette table dans la base de données cible. Pour plus d'informations, consultez Object name mapping.

        • Schema Migration : ignore la vérification des tables homonymes.

          Avertissement

          La sélection de l'option Full Data Migration 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 cohérents et qu'un enregistrement de la base de données cible 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 cible. 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 cible. L'enregistrement provenant de la base de données source écrase celui de la base de données cible.

          • 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.

        Incremental Data Migration

        Dans la zone Schema Migration, cliquez sur les objets à migrer, puis cliquez sur Right arrow pour les déplacer vers la zone Selected Objects.

        Remarque

        La granularité de sélection des objets de migration concerne les schémas, les tables et les colonnes. 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 seront pas migrés vers la base de données cible.

        Selected Objects

        • Pour modifier le nom d'un seul objet de migration dans l'instance cible, faites un clic droit sur l'objet dans la zone Selected Objects. Pour plus d'informations, consultez Map individual schema, table, and column names.

        • Pour modifier les noms de plusieurs objets de migration dans l'instance cible, cliquez sur Precheck and Report Errors dans le coin supérieur droit de la zone Ignore Errors and Proceed. Pour plus d'informations, consultez Map multiple schema, table, and column names.

        Remarque

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

        • Pour filtrer les données à l'aide de conditions WHERE, faites un clic droit sur une table dans le volet Ignore Errors and Proceed et spécifiez les conditions de filtrage dans la boîte de dialogue qui s'affiche. Pour plus d'informations, consultez Set filter conditions.

        • Pour sélectionner les opérations DDL ou DML pour la migration incrémentielle des données au niveau de la base de données ou de la table, faites un clic droit sur un objet de migration dans le volet Source Objects et sélectionnez les opérations DML et DDL requises dans la boîte de dialogue qui s'affiche.

      2. Cliquez sur Source Objects pour configurer les paramètres avancés.

        Parameter

        Description

        Selected Objects

        Par défaut, DTS planifie les tâches sur un cluster partagé. Aucune sélection n'est requise. Si vous souhaitez des tâches plus stables, vous pouvez acheter un dedicated cluster pour exécuter les tâches de migration DTS.

        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 cible é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 1 440 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 cible dans le délai imparti, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue.

        Remarque

        • Pour plusieurs instances DTS partageant la même source ou la même destination, le temps de nouvelle tentative réseau est déterminé 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 cible.

        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 cible, 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 1 440 minutes. Nous vous recommandons de définir une durée supérieure à 10 minutes. Si les opérations associées réussissent dans le délai de nouvelle tentative spécifié, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue.

        Important

        La valeur de Selected Objects doit être inférieure à la valeur de Batch Edit.

        Selected Objects

        Lors de la migration complète, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et cible, ce qui peut augmenter la charge de la base de données. Si nécessaire, vous pouvez activer la limitation du débit pour la tâche de migration complète. Vous pouvez définir les paramètres Selected Objects, Next: Advanced Settings et Dedicated Cluster for Task Scheduling afin de réduire la charge sur la base de données cible.

        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 l'instance de migration en cours d'exécution.

        Retry Time for Other Issues

        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 Retry Time for Failed Connections et Enable Throttling for Full Data Migration afin de réduire la charge sur la base de données cible.

        Remarque

        • Cet élément de configuration est disponible uniquement si vous sélectionnez Queries per second (QPS) to the source database pour RPS of Full Data Migration.

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

        Data migration speed for full migration (MB/s)

        Vous pouvez sélectionner un tag d'environnement pour identifier l'instance. Dans cet exemple, il n'est pas nécessaire de sélectionner un tag.

        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.

        • Enable Throttling for Incremental Data Migration : é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.

        RPS of Incremental Data Migration

        En fonction de vos besoins métier, choisissez de configurer ou non la fonctionnalité ETL pour traiter les données.

        • Data migration speed for incremental migration (MB/s) : configure la fonctionnalité ETL. Vous devez également saisir des instructions de traitement des données dans la zone de texte.

        • Incremental Data Migration : ne configure pas la fonctionnalité ETL.

        Migration Types

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

        • Environment Tag : 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 Yes pour configurer une tâche de validation des données.

        Pour plus d'informations sur la fonctionnalité de validation des données, consultez 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 No et cliquez sur Configure ETL 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 Yes 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 réussite de cette prévérification.

      • Si la prévérification échoue, cliquez sur No à 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 Monitoring and Alerting à 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 pouvant être ignorés, vous pouvez cliquer sur No, Ignore, Next: Data Validation et Next: Save Task Settings and Precheck 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 qu'une incohérence des données et présenter des risques pour votre activité.

    7. Achetez l'instance de migration.

      1. Lorsque le Preview OpenAPI parameters atteint 100 %, cliquez sur Next: Save Task Settings and Precheck.

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

        Catégorie

        Paramètre

        Description

        View Details

        Confirm Alert Details

        Sélectionnez le groupe de ressources auquel appartient l'instance. La valeur par défaut est « default resource group ». Pour plus d'informations, consultez Qu'est-ce que la gestion des ressources ?

        Ignore

        DTS propose des spécifications de migration avec différents niveaux de performance. La spécification de lien 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 Spécifications des liens de migration de données.

      3. Une fois la configuration terminée, lisez et acceptez les OK.

      4. Cliquez sur Precheck Again. Dans la boîte de dialogue Success Rate qui s'affiche, cliquez sur Next: Purchase Instance.

        Vous pouvez consulter 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 New Instance Class passe à Resource Group Settings.

        • 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 Instance Class de la tâche est Data Transmission Service (Pay-as-you-go) Service Terms.