Migrate RDS MySQL to MaxCompute - Data Transmission Service - Centre de documentation Alibaba Cloud

Prérequis

Créez un projet MaxCompute de destination disposant d'un espace de stockage supérieur à celui utilisé par l'instance ApsaraDB RDS for MySQL source. Pour plus d'informations, consultez Créer un projet MaxCompute.
Configurez une liste d'autorisation d'adresses IP pour MaxCompute afin d'autoriser l'accès depuis DTS. Pour plus d'informations, consultez Configurer une liste d'autorisation d'adresses IP pour permettre aux services Alibaba Cloud d'accéder à MaxCompute.
Utilisez un compte Alibaba Cloud (compte principal) pour créer et enregistrer une paire d'AccessKey.

Remarque
Vous pouvez également créer un utilisateur RAM et enregistrer sa paire d'AccessKey, puis lui attribuer un rôle de super administrateur (admin ou super_administrator).

Limites

Remarque

DTS ne migre pas les clés étrangères. Par conséquent, les opérations en cascade, telles que la suppression en cascade dans la base de données source, ne sont pas répliquées dans la base de données de destination.

Type	Description
Limites de la base de données source	Les tables migrées doivent posséder une clé primaire ou une contrainte unique, et les valeurs des colonnes correspondantes doivent être uniques. Dans le cas contraire, la base de données de destination risque de contenir des données en double. Lors d'une migration au niveau des tables avec des opérations d'édition telles que le mappage de noms de colonnes, une seule tâche de migration prend en charge jusqu'à 1 000 tables. L'envoi d'une tâche comportant davantage de tables génère une erreur. Nous vous recommandons de répartir les tables sur plusieurs tâches de migration ou de configurer une tâche unique pour migrer l'intégralité de la base de données. 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 à deux maîtres, où chaque instance agit à la fois comme maître et esclave, activez le paramètre log_slave_updates. Cela garantit que DTS puisse 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, cela peut entraîner une incohérence ou une perte de données. Les problèmes causés par des durées 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 Automatically delete local logs. Pendant les phases de migration du schéma et de migration complète, n'exécutez pas d'opérations DDL modifiant le schéma de la base de données ou des tables. Cela provoquerait l'échec de la tâche de migration des données. Remarque Durant la phase de migration complète, DTS interroge la base de données source. Cette opération crée un verrou de métadonnées susceptible de bloquer les opérations DDL sur la base de données source. Si vous effectuez uniquement une migration complète des données, n'écrivez pas de nouvelles données dans la base de données source. Cela créerait des incohérences entre les bases de données source et de destination. Pour garantir une cohérence des données en temps réel, sélectionnez la migration du schéma, la migration complète des données et la migration incrémentielle des données. Si une migration incrémentielle est nécessaire, 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 ne migre pas les données générées par des modifications qui ne sont pas écrites dans les journaux binaires. C'est notamment le cas des données restaurées à partir de sauvegardes physiques ou créées par des opérations en cascade. Remarque Si cette situation se présente, relancez une 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. 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 masquée visible. Pour plus d'informations, consultez Invisible Columns.
Autres limites	DTS ne prend pas en charge la migration des types d'objets suivants : INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER et les clés étrangères (FK). MaxCompute ne prenant pas en charge les contraintes de clé primaire, si DTS retransmet des données en raison de problèmes réseau ou pour d'autres raisons, des enregistrements en double peuvent apparaître dans MaxCompute. N'utilisez pas d'outils tels que pt-online-schema-change pour effectuer des modifications DDL en ligne sur les objets de migration dans la base de données source. Cela provoquerait l'échec de la tâche de migration. Pour les colonnes de type de données FLOAT ou DOUBLE, DTS lit les valeurs à l'aide de la fonction `ROUND(COLUMN,PRECISION)`. Si vous ne spécifiez pas la précision, DTS utilise une précision par défaut de 38 chiffres pour FLOAT et de 308 chiffres pour DOUBLE. Assurez-vous que la précision de la migration répond aux exigences de votre activité. Avant de lancer la migration des données, évaluez les performances des bases de données source et de destination. Il est recommandé d'effectuer la migration pendant les heures creuses, car la migration complète des données consomme des ressources de lecture et d'écriture sur les deux bases de données et peut augmenter la charge de travail. La migration complète des données implique des opérations INSERT concurrentes, ce qui provoque une fragmentation des tables dans la base de données de destination. Après la migration complète, les tables de la base de données de destination occuperont plus d'espace de stockage que dans l'instance source. DTS tente de reprendre les tâches pour les instances de migration ayant échoué dans un délai de sept jours. Par conséquent, avant de basculer vos charges de travail vers l'instance de destination, vous devez arrêter ou libérer l'instance DTS, ou utiliser l'instruction `REVOKE` pour révoquer les permissions d'écriture du compte utilisé par DTS pour accéder à l'instance de destination. Cela empêche la reprise automatique de la tâche, qui pourrait entraîner l'écrasement des données de l'instance de destination par les données sources. Si le chiffrement Always-Encrypted est activé sur votre instance RDS for MySQL, la migration complète n'est pas prise en charge. Remarque Les instances RDS for MySQL avec le chiffrement transparent des données (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 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 la tâche DTS sont modifiés, et non les paramètres de la base de données. Les paramètres susceptibles d'être ajustés incluent ceux listés dans Modify instance parameters.
Cas particuliers	Pour les sources MySQL auto-gérées : Un basculement maître-veille 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 inexact. 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 toute la base de données, créez une table de battement de cœur. Mettez-la à jour ou écrivez-y toutes les secondes. DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS `test` sur la base de données source pour faire avancer le décalage 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 de lecture-écriture (RW). Sinon, la tâche de migration risque d'échouer. Pour les sources RDS for MySQL : Si une migration incrémentielle est nécessaire, 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 le décalage du journal binaire.

Facturation

Type de migration	Frais de configuration de la tâche	Frais de trafic Internet
Migration du schéma et migration complète des données	Gratuit.	Gratuit dans cet exemple. Remarque Le réglage de l'Access Method de la base de données de destination sur Public IP Address engendre des frais de trafic Internet. Pour plus d'informations, consultez Billing overview.
Migration incrémentielle des données	Payant. Pour plus d'informations, consultez Billing overview.

Types de migration

Migration du schéma

DTS migre les schémas des tables sources vers MaxCompute et ajoute le suffixe _base aux noms des tables lors de l'initialisation. Par exemple, si une table source est nommée customer, la table correspondante dans MaxCompute sera nommée customer_base.
Migration complète des données

DTS migre toutes les données historiques des tables sources vers les tables _base dans MaxCompute. Ces données servent de base de référence pour la migration incrémentielle ultérieure. Par exemple, les données de la table customer de la base de données source sont migrées vers la table customer_base dans MaxCompute.

Remarque
Cette table est également appelée table de référence complète.
Migration incrémentielle des données

DTS crée une table de journal incrémentiel dans MaxCompute et migre les données incrémentielles de la base de données source vers cette table en temps réel. Le nom de la table est obtenu en ajoutant le suffixe _log au nom de la table source, par exemple customer_log.

Remarque
Pour plus d'informations sur le schéma de la table de journal incrémentiel, consultez Schéma de la table de journal incrémentiel.

Opérations SQL pour la migration incrémentielle

Type	Instruction SQL
DML	INSERT, UPDATE, DELETE
DDL	ADD COLUMN Remarque Les opérations ADD COLUMN avec attributs ne sont pas prises en charge.

Permissions des comptes de base de données

Base de données	Schema migration	Full data migration	Incremental data migration
RDS MySQL	Permission SELECT	Permission SELECT	REPLICATION SLAVE, REPLICATION CLIENT et la permission SELECT sur les objets à migrer. DTS accorde automatiquement ces permissions.
MaxCompute	Permissions de lecture et d'écriture

Pour créer un compte de base de données RDS MySQL et attribuer des permissions, consultez Créer un compte et Modifier les permissions du compte.

Procédure

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 + AI > Data Transmission (DTS) > Data Migration.
3. À droite de Data Migration Tasks, sélectionnez la région où se trouve l'instance de migration.
Cliquez sur Create Task pour accéder à la page de configuration des tâches.

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

Catégorie	Paramètre	Description
N/A	Task Name	DTS génère automatiquement un nom de tâche. Utilisez un nom descriptif pour faciliter l'identification. Ce nom n'a pas besoin d'être unique.
Source 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 souhaitée dans la liste déroulante. Les informations de la 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 dans le système, ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de la base de données ci-dessous.
	Database Type	Sélectionnez MySQL.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région de l'instance RDS MySQL source.
	Replicate Data Across Alibaba Cloud Accounts	Dans cet exemple, une instance de base de données sous le compte Alibaba Cloud actuel est utilisée. Sélectionnez No.
	RDS Instance ID	Sélectionnez l'ID d'instance de l'instance RDS MySQL source.
	Database Account	Saisissez le compte de base de données de l'instance RDS MySQL source. Pour plus d'informations sur les permissions requises, consultez Permissions requises pour les comptes de base de données.
	Database Password	Saisissez le mot de passe du compte de base de données.
	Connection Method	Sélectionnez Non-encrypted ou SSL-encrypted selon les exigences de votre base de données. Si vous définissez ce paramètre sur SSL-encrypted, vous devez préalablement activer le chiffrement SSL pour l'instance RDS for MySQL. 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 souhaitée dans la liste déroulante. Les informations de la 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 dans le système, ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de la base de données ci-dessous.
	Database Type	Sélectionnez MaxCompute.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région du projet MaxCompute cible.
	Project	Saisissez le nom du projet MaxCompute cible.
	AccessKey ID of Alibaba Cloud Account	Saisissez la paire AccessKey que vous avez préparée dans la section Prérequis.
	AccessKey Secret of Alibaba Cloud Account

Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page.
Remarque
- Vérifiez que le segment d'adresse 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 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.
Cliquez sur OK pour autoriser le compte MaxCompute.

Configurez les objets de la tâche.

Dans la page Configure Objects, configurez les objets à migrer.

Paramètre	Description
Migration Types	Pour effectuer uniquement une migration complète, sélectionnez à la fois Schema Migration et Full Data Migration. Afin de réaliser une migration sans interruption de service, sélectionnez Schema Migration, Full Data Migration ainsi que Incremental Data Migration. Remarque Si vous ne sélectionnez pas Schema Migration, assurez-vous qu'une base de données et des tables destinées à recevoir les données existent déjà dans la base de données cible. Vous pouvez également recourir à la fonctionnalité de mappage des noms d'objets dans la zone Selected Objects selon vos besoins. En l'absence de sélection de Incremental Data Migration, évitez d'écrire de nouvelles données dans l'instance source pendant la migration afin de garantir la cohérence des données.
Naming Rules of Additional Columns	Lorsque DTS migre des données vers MaxCompute, il ajoute des colonnes supplémentaires aux tables cibles. Choisissez New Rule ou Previous Rule en fonction de vos exigences métier. Avertissement Avant de sélectionner une règle, vérifiez si les noms des colonnes supplémentaires entrent en conflit avec ceux des colonnes existantes dans les tables cibles. De tels conflits peuvent provoquer l'échec de la migration ou entraîner une perte de données. Pour plus d'informations sur les règles et les définitions des colonnes supplémentaires, consultez Noms et définitions des colonnes supplémentaires.
Partition Definition of Incremental Data Table	Sélectionnez un nom de partition selon vos besoins métier. Pour plus d'informations sur les partitions, consultez Partition.
Processing Mode of Conflicting Tables	Precheck and Report Errors : Vérifie si des tables portant le même nom existent dans la base de données cible. En l'absence de tables homonymes, la pré-vérification est validée. Si des tables homonymes sont détectées, 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 cible porte le même nom mais ne peut être facilement supprimée ou renommée, vous pouvez modifier son nom dans la base de données cible. Pour plus d'informations, consultez Mappage des noms d'objets. Ignore Errors and Proceed : Ignore la vérification des tables homonymes. Avertissement La sélection de Ignore Errors and Proceed peut entraîner une incohérence des données et présenter des risques opérationnels. Par exemple : Si les schémas des tables 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é. Durant la migration incrémentielle, DTS ne conserve pas l'enregistrement dans la base de données cible. L'enregistrement source écrase alors celui présent dans la base de données cible. Si les schémas des tables sont incohérents, seules certaines colonnes de données risquent d'être migrées, ou la migration peut échouer. Faites preuve de prudence.
Capitalization of Object Names in Destination Instance	Vous avez la possibilité de configurer la politique de sensibilité à la casse pour les noms des objets migrés (bases de données, tables, colonnes) dans l'instance cible. Par défaut, l'option DTS default policy est sélectionnée. Vous pouvez également choisir d'aligner la sensibilité à la casse sur la politique par défaut de la base de données source ou cible. Pour plus d'informations, consultez Sensibilité à la casse des noms d'objets dans la base de données cible.
Source Objects	Sélectionnez un ou plusieurs objets dans la section Source Objects. Cliquez sur l'icône pour ajouter ces objets à la section Selected Objects. Remarque La sélection des objets s'effectue uniquement au niveau de la table.
Selected Objects	Pour renommer un objet de migration unique dans l'instance cible, faites un clic droit sur cet objet dans la zone Selected Objects. Pour plus d'informations, consultez Mapper des noms de schéma, de table et de colonne individuels. Afin de renommer plusieurs objets de migration dans l'instance cible, cliquez sur Selected Objects dans le coin supérieur droit de la zone Batch Edit. Pour plus d'informations, consultez Mapper plusieurs noms de schéma, de table et de colonne. Remarque L'utilisation de la fonctionnalité de mappage des noms d'objets risque de provoquer l'échec de la migration d'autres objets dépendant de l'objet renommé. Pour filtrer des données à l'aide d'une clause WHERE, faites un clic droit sur la table à migrer dans la zone Selected Objects, puis spécifiez les conditions de filtrage dans la boîte de dialogue qui s'affiche. Pour obtenir des instructions, consultez Configurer des conditions de filtrage. Afin de sélectionner les opérations SQL à migrer au niveau de la base de données ou de la table, faites un clic droit sur l'objet concerné dans la zone Selected Objects et choisissez les opérations SQL souhaitées dans la boîte de dialogue qui s'affiche.

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é ; aucune sélection n'est donc requise. Si vous souhaitez bénéficier d'une exécution plus stable, vous pouvez acquérir un cluster dédié pour exécuter les tâches de migration DTS.
Retry Time for Failed Connections	Une fois la tâche de migration lancée, si la connexion à la base de données source ou cible échoue, DTS signale une erreur et tente immédiatement de se reconnecter. 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. Il est recommandé de définir une valeur supérieure à 30 minutes. Si DTS parvient à rétablir la connexion 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 cible, le temps de nouvelle tentative réseau est déterminé par le paramétrage de la dernière tâche créée. Étant donné que la tâche reste facturable durant la période de nouvelle tentative de connexion, nous vous conseillons d'ajuster ce délai selon vos besoins métier, ou de libérer l'instance DTS dès que possible après la suppression des instances de base de données source et cible.
Retry Time for Other Issues	Après le démarrage de la tâche de migration, si un problème autre qu'un échec de connexion survient dans la base de données source ou cible (par exemple, une exception d'exécution DDL ou DML), DTS signale une erreur et relance immédiatement 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. Il est recommandé de définir une valeur supérieure à 10 minutes. Si les opérations concernées réussissent dans le délai de nouvelle tentative spécifié, la tâche de migration reprend automatiquement. Sinon, la tâche échoue. Important La valeur de Retry Time for Other Issues doit être inférieure à celle de Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Durant 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 accroître leur charge. Si nécessaire, activez la limitation de débit pour la tâche de migration complète. Définissez les paramètres Queries per second (QPS) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s) afin de réduire la charge sur la base de données cible. Remarque Ce paramètre de configuration n'est disponible que si vous avez sélectionné Full Data Migration dans Migration Types. Il est également possible d'ajuster la vitesse de migration complète une fois l'instance de migration en cours d'exécution.
Enable Throttling for Incremental Data Migration	Au besoin, vous pouvez également définir des limites de vitesse pour la tâche de migration incrémentielle. Configurez les paramètres RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s) pour alléger la charge sur la base de données cible. Remarque Ce paramètre de configuration n'est accessible que si vous avez sélectionné Incremental Data Migration dans Migration Types. Vous avez aussi la possibilité d'ajuster la vitesse de migration incrémentielle après le lancement de l'instance de migration.
Whether to delete SQL operations on heartbeat tables of forward and reverse tasks	Décidez s'il faut écrire ou non les informations SQL de battement de cœur dans la base de données source lorsque l'instance DTS est en cours d'exécution. Yes : Les informations SQL de battement de cœur ne sont pas écrites dans la base de données source. Cela peut amener l'instance DTS à signaler un retard. No : Les informations SQL de battement de cœur sont écrites dans la base de données source. Cela risque d'interférer avec certaines fonctionnalités telles que la sauvegarde physique et le clonage de la base de données source.
Environment Tag	Sélectionnez un tag d'environnement pour identifier l'instance. Ce paramètre est facultatif.
Configure ETL	Indiquez si vous souhaitez activer la fonctionnalité d'extraction, transformation et chargement (ETL). Pour plus d'informations, consultez Qu'est-ce que l'ETL ? Valeurs valides : Yes : Active la fonctionnalité ETL. Saisissez les instructions de traitement des données dans l'éditeur de code. Pour plus d'informations, consultez Configurer l'ETL dans une tâche de migration ou de synchronisation des données. No : Désactive la fonctionnalité ETL.
Monitoring and Alerting	Choisissez de configurer ou non des alertes et de recevoir des notifications en fonction de vos besoins métier. No : Aucune alerte n'est configurée. 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 défini, le système envoie une notification d'alerte.

Enregistrez la tâche et lancez une pré-vérification.
- Pour consulter les paramètres de configuration de cette instance lors de l'appel à l'API, placez le pointeur de la souris sur le bouton Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters dans l'infobulle qui apparaît.
- Si vous n'avez pas besoin de consulter les paramètres API ou si vous avez terminé leur examen, 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ébute qu'une fois cette étape validée.
- En cas d'échec de la pré-vérification, cliquez sur View Details en regard de l'élément ayant échoué, corrigez le problème en suivant les indications fournies, puis relancez la pré-vérification.
- Si un avertissement est signalé lors de la pré-vérification :
  
  Pour les éléments de contrôle non ignorables, cliquez sur View Details en regard de l'élément concerné, résolvez le problème selon les instructions affichées, puis exécutez à nouveau la pré-vérification.
  
  Concernant les éléments de contrôle pouvant être ignorés, cliquez successivement sur Confirm Alert Details, Ignore, OK et Precheck Again pour passer outre l'avertissement et relancer la pré-vérification. Notez qu'ignorer un avertissement peut engendrer des problèmes tels que l'incohérence des données et présenter des risques pour votre activité.

Acquérez l'instance.

Lorsque le Success Rate atteint 100 %, cliquez sur Next: Purchase Instance.

Dans la page Purchase, sélectionnez la spécification de lien pour l'instance de migration de données. Consultez le tableau suivant pour plus d'informations.

Catégorie	Paramètre	Description
New Instance Class	Resource Group Settings	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 Resource Management ?
New Instance Class	Instance Class	DTS propose des spécifications de migration offrant différents niveaux de performance. La spécification de lien influe sur la vitesse de migration. Choisissez une spécification adaptée à votre scénario métier. 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 suivre la progression de la tâche de migration dans 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 à la fin de la migration complète. Son Status passe alors à Completed.
- En revanche, si la tâche comprend une migration incrémentielle, elle ne s'arrête pas automatiquement et la phase incrémentielle se poursuit. Pendant cette phase, le Status de la tâche est Running.

Schéma de la table de journaux incrémentiels