Migrer des données d'une instance ApsaraDB RDS for MySQL vers un cluster AnalyticDB for MySQL V3.0 - Data Transmission Service

Cette rubrique explique comment migrer des données d'une instance ApsaraDB RDS for MySQL vers un cluster AnalyticDB for MySQL V3.0 à l'aide de Data Transmission Service (DTS). Une fois la migration terminée, vous pouvez utiliser AnalyticDB for MySQL pour construire des systèmes internes de business intelligence (BI), des systèmes de requêtes interactives et des systèmes de rapports en temps réel.

Prérequis

Le cluster de destination AnalyticDB for MySQL V3.0 est créé. Pour plus d'informations, consultez Créer un cluster.
L'espace de stockage disponible du cluster AnalyticDB for MySQL de destination doit être supérieur à la taille totale des données de l'instance source ApsaraDB RDS for MySQL.

Limites

Type	Description
Limites de la base de données source	Bande passante : le serveur hébergeant la base de données source doit disposer d'une bande passante sortante suffisante, faute de quoi la vitesse de migration diminuera. Chaque table à migrer doit posséder une clé primaire ou une contrainte UNIQUE, et les colonnes clés 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 complète de la base de données. Pour 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 autogé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 autogé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 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 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 du schéma ou la migration complète, sous peine d'échec de la tâche de migration. 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. N'exécutez pas d'opérations DDL qui ajoutent des commentaires, telles que `ALTER TABLE table_name COMMENT='Table comment';`, sous peine d'échec de la tâche de migration. 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 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 de données MySQL source est en version 8.0.23 ou ultérieure et contient des colonnes masquées invisibles, DTS ne peut pas lire ces colonnes, ce qui 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 masqué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. 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 (par exemple, lorsqu'OceanBase est connecté en tant que 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	Les index de préfixe ne sont pas pris en charge. Si votre base de données source contient des index de préfixe, la migration peut échouer. DTS ne prend pas en charge la migration des objets INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER ou FK. 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. 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 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 : 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 celui de 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. Agissez avec prudence. La base de données de destination doit posséder une clé primaire personnalisée. Ou, à l'étape Configurations for Databases, Tables, and Columns, définissez la Primary Key Column. Sinon, la migration peut échouer. En raison des limites intégrées de AnalyticDB for MySQL, si l'utilisation de l'espace disque sur les nœuds dépasse 80 %, les tâches DTS deviennent anormales et subissent des retards. Estimez l'espace requis à l'avance en fonction des objets à migrer et assurez-vous que le cluster de destination dispose d'un espace de stockage suffisant. Si le cluster de destination AnalyticDB for MySQL 3.0 effectue une sauvegarde pendant l'exécution de la tâche DTS, la tâche échoue. 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é, car la migration complète consomme des ressources de lecture et d'écriture sur les deux bases de données et augmente leur charge. La migration complète exécute des opérations INSERT de manière concurrente, ce qui 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 aux besoins de votre activité. 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 les écritures DDL échouent sur la base de données 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 obtenir des instructions, consultez Afficher les journaux de tâche. 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. En cas d'échec d'une tâche, l'équipe d'assistance DTS tentera de la restaurer dans un délai de huit heures. Pendant 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 pouvant être ajustés incluent ceux répertoriés dans Modifier les paramètres de l'instance.
Cas particuliers	Pour les sources MySQL autogé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 complète de la base de données, 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 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 — et 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 en tant que 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 du 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, des frais de trafic Internet vous sont facturés. 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 du schéma

DTS migre les schémas des objets requis de la base de données source vers la base de données de destination.

Remarque
ApsaraDB RDS for MySQL et AnalyticDB for MySQL sont des bases de données hétérogènes. DTS ne garantit pas que les schémas des bases de données source et de destination soient cohérents après la migration du schéma. Nous vous recommandons d'évaluer l'impact de la conversion des types de données sur votre activité. Pour plus d'informations, consultez

Mappages de types de données pour les bases de données hétérogènes

.
Migration complète des données

DTS migre les données historiques des objets requis de la base de données source vers la base de données de destination.
Migration incrémentielle des données

Une fois la migration complète des données terminée, DTS synchronise les données incrémentielles de la base de données source vers la base de données de destination. La migration incrémentielle des données vous permet d'assurer la continuité du service lors de la migration de données entre des bases de données autogérées.

Opérations SQL pouvant être migrées

Type d'opération	Instructions SQL
DML	INSERT, UPDATE et DELETE
DDL	CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, ADD COLUMN et DROP COLUMN

Avertissement

Si le type de données d'un champ de la table source est modifié pendant la migration des données, un message d'erreur est généré et la tâche de migration des données est arrêtée. Vous pouvez

soumettre un ticket

ou suivre les étapes suivantes pour résoudre le problème.

Lorsque DTS migre des données vers le cluster AnalyticDB for MySQL de destination, le type de données d'un champ nommé customer dans la table source est modifié. Par conséquent, la tâche de migration des données échoue.
Dans le cluster AnalyticDB for MySQL V3.0 de destination, créez une table nommée customer_new. La table customer_new possède le même schéma que la table customer.
Exécutez la commande INSERT INTO SELECT pour copier les données de la table customer et les insérer dans la table customer_new. Cela garantit la cohérence des données entre les deux tables.
Renommez ou supprimez la table customer. Ensuite, renommez la table customer_new en customer.
Redémarrez la tâche de migration des données dans la console DTS.

Autorisations requises pour les comptes de base de données

Base de données	Migration du schéma	Migration complète	Migration incrémentielle
ApsaraDB RDS for MySQL	Autorisation SELECT	Autorisation SELECT	Autorisation SELECT sur les objets à migrer, autorisation REPLICATION SLAVE et autorisation REPLICATION CLIENT. DTS accorde automatiquement ces autorisations au compte de base de données.
AnalyticDB for MySQL V3.0	Autorisations de lecture et d'écriture

Pour plus d'informations sur la création et l'autorisation d'un compte de base de données, consultez les rubriques suivantes :

Instance ApsaraDB RDS for MySQL : Créer un compte et Modifier les autorisations d'un compte standard sur une instance ApsaraDB RDS for MySQL
Cluster AnalyticDB for MySQL V3.0 : Créer un compte de base de données

Procédure

Connectez-vous à la page Tâches de migration de données de la nouvelle console DTS.

Remarque
Vous pouvez également vous connecter à la console Data Management (DMS). Dans la barre de menu supérieure, choisissez Data + AI > Data Migration.
Dans le coin supérieur gauche de la page, sélectionnez la région où se trouve l'instance de migration.

Cliquez sur Create Task et 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.

Configure the source and destination databases

Section	Paramètre	Description
S.O.	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	Database Type	Sélectionnez MySQL.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région où réside l'instance ApsaraDB RDS for MySQL source.
	Cross-account	Dans cet exemple, sélectionnez No car les données sont migrées au sein du même compte Alibaba Cloud.
	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 plus d'informations sur les autorisations requises pour le compte, 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.
Destination Database	Database Type	Sélectionnez AnalyticDB for MySQL 3.0.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région où réside le cluster AnalyticDB for MySQL V3.0 de destination.
	Instance ID	Sélectionnez l'ID du cluster AnalyticDB for MySQL V3.0 de destination.
	Database Account	Saisissez le compte de base de données du cluster AnalyticDB for MySQL V3.0 de destination. Pour plus d'informations sur les autorisations requises pour le compte, 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.

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 blocs CIDR des serveurs DTS à la liste blanche d'adresses IP de l'instance. Si la base de données source ou de destination est une base de données autogérée hébergée sur une instance ECS, DTS ajoute automatiquement les blocs CIDR des serveurs DTS aux règles de 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 autogérée est hébergée sur plusieurs instances ECS, vous devez ajouter manuellement les blocs CIDR des serveurs DTS aux règles de groupe de sécurité de chaque instance ECS. Si la base de données source ou de destination est une base de données autogé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 blocs CIDR des serveurs DTS à la liste blanche d'adresses 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 Blocs CIDR des serveurs DTS.

Avertissement
L'ajout des blocs 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 forts, la limitation des ports ouverts pour chaque bloc CIDR, l'utilisation de l'authentification pour les appels API internes et la vérification et la restriction régulières des blocs CIDR inutiles. Vous pouvez également vous connecter via un réseau interne, tel qu'une ligne louée, une passerelle VPN ou Smart Access Gateway.

Configurez les objets de la tâche et les paramètres avancés.

Basic Settings

Paramètre	Description
Migration Types	Si vous devez uniquement effectuer 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 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 de noms d'objets 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.
Processing Mode for Existing Destination Tables	Precheck and Report Errors : Vérifie si des tables portant les mêmes noms existent dans la base de données de destination. Si aucune table portant le même nom n'existe, la pré-vérification est réussie. 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 données 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 données de destination. Pour plus d'informations, consultez Mappage de noms d'objets. 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 une incohérence des données et des risques commerciaux. Par exemple : 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 : 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 celui de 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. Agissez avec prudence.
Select DDL and DML to Sync at the Instance Level	Sélectionnez les opérations SQL que vous souhaitez migrer au niveau de l'instance. Pour plus d'informations, consultez Opérations SQL pouvant être migrées Remarque Pour sélectionner les opérations SQL effectuées sur une base de données ou une table spécifique, procédez comme suit : Dans la section Selected Objects, faites un clic droit sur un objet. Dans la boîte de dialogue qui s'affiche, sélectionnez les opérations SQL que vous souhaitez migrer.
Table Merging	Si vous sélectionnez Yes, DTS ajoute la colonne `__dts_data_source` à chaque table pour enregistrer les sources de données. Pour plus d'informations, consultez Activer la fusion multi-tables. Si vous sélectionnez No, il s'agit de l'option par défaut. Remarque La fonctionnalité de fusion de tables est configurée au niveau de la tâche, et non au niveau de la table. Pour fusionner certaines tables mais pas d'autres, vous devez créer deux tâches de migration de données distinctes. Avertissement N'effectuez pas d'opérations DDL pour modifier le schéma de la base de données source ou des tables. Sinon, une incohérence des données ou un échec de la tâche peut survenir.
Source Objects	Dans la zone Source Objects, cliquez sur les objets à migrer, puis cliquez sur pour les déplacer vers la zone Selected Objects. Remarque
Change mapped name	Pour modifier le nom d'un seul objet de migration dans l'instance de destination, faites un clic droit sur l'objet dans la zone Selected Objects. Pour plus d'informations sur la définition du nom, consultez Mapper un nom de table ou de colonne unique. Pour modifier les noms de plusieurs objets de migration par lot, cliquez sur Batch Edit dans le coin supérieur droit de la zone Selected Objects. Pour plus d'informations sur la définition des noms, consultez Mapper plusieurs noms de tables ou de colonnes par lot. Remarque Si vous utilisez la fonctionnalité de mappage de noms d'objets, d'autres objets dépendant de l'objet mappé peuvent échouer à migrer.
Filter data to migrate	Vous pouvez définir des conditions pour filtrer les données. Pour plus d'informations, consultez Définir des conditions de filtrage.
SQL operations for incremental migration	Dans la section Selected Objects, faites un clic droit sur un objet. Dans la boîte de dialogue qui s'affiche, sélectionnez les opérations SQL que vous souhaitez migrer. Pour plus d'informations, consultez Opérations SQL pouvant être migrées.

Advanced Settings

Paramètre	Description
Monitoring and Alerting	Sélectionnez si vous souhaitez configurer des alertes et recevoir des notifications d'alerte en fonction des besoins de votre activité. No : Ne configure 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.
Capitalization of Object Names in Destination Instance	Vous pouvez configurer la politique de sensibilité à la casse pour les noms des objets migrés, tels que les bases de données, les tables et les colonnes, dans l'instance de destination. Par défaut, DTS default policy est sélectionné. Vous pouvez également choisir de conserver la sensibilité à la casse conforme à la politique par défaut de la base de données source ou de destination. Pour plus d'informations, consultez Sensibilité à la casse des noms d'objets dans la base de données de destination.
Copy temporary tables created by online DDL tools from 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 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 qui modifient la structure de la base de données 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 en fonction 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 provoquer 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 migre uniquement les instructions DDL originales exécutées à l'aide de Data Management (DMS). 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. 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 en fonction des règles d'expression régulière. Vous pouvez modifier les expressions régulières par défaut utilisées pour correspondre aux 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.
Retry Time for Failed Connections	Après le démarrage de la tâche de migration, si la connexion à la base de données source ou de destination échoue, DTS signale une erreur et commence immédiatement à réessayer 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 de données 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, 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 vous êtes facturé pour la tâche pendant la période de nouvelle tentative de connexion, nous vous recommandons de personnaliser la durée de nouvelle tentative en fonction des besoins de votre activité, 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.

Facultatif : Une fois les configurations précédentes terminées, cliquez sur Next: Configure Database and Table Fields pour définir le Type, la Primary Key Column, la Distribution Key et les informations de clé de partition (Partition Key, Partitioning Rules et Partition Lifecycle) pour les tables à migrer dans la base de données de destination.
Remarque
- Cette étape est disponible uniquement si vous sélectionnez l'option Schema Migration pour Migration Types lors de la configuration des objets de la tâche. Vous pouvez sélectionner All pour Definition Status afin d'effectuer des modifications.
- Vous pouvez sélectionner plusieurs colonnes pour Primary Key Column afin de former une clé primaire composite. Vous devez également sélectionner une ou plusieurs colonnes de la Primary Key Column à utiliser comme Distribution Key et Partition Key. Pour plus d'informations, consultez CREATE TABLE.
Une fois les configurations terminées, cliquez sur Next: Save Task Settings and Precheck en bas de la page.
Vous pouvez placer le pointeur sur le bouton Next: Save Task Settings and Precheck et cliquer sur Preview OpenAPI parameters dans la bulle qui apparaît pour afficher les paramètres de configuration de cette instance lors de l'appel de l'opération API.
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 en suivant 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 en suivant 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 et 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 qu'une incohérence des données et présenter des risques pour votre activité.
Lorsque le Success Rate est de 100 %, cliquez sur Next: Purchase Instance.

Sur la page Purchase, 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
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 ?
New Instance Class	Instance Class	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 d'activité. Pour plus d'informations, consultez Spécifications de lien de migration de données.

Une fois la configuration terminée, lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.
Cliquez sur Buy and Start. Dans la boîte de dialogue OK qui s'affiche, cliquez sur OK.

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