Migrate a standalone MongoDB instance to any architecture - Data Transmission Service

Utilisez Data Transmission Service (DTS) pour migrer intégralement une instance autonome MongoDB vers une instance ApsaraDB for MongoDB de n'importe quelle architecture.

Bases de données source et de destination

Base de données source	Base de données de destination
ApsaraDB for MongoDB	ApsaraDB for MongoDB
Base de données auto-gérée sur une instance ECS	Base de données auto-gérée sur une instance 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 Express Connect, VPN Gateway ou Smart Access Gateway
Base de données auto-gérée avec une adresse IP publique	Base de données auto-gérée avec une adresse IP publique

Cette rubrique illustre la procédure de configuration en utilisant une instance ApsaraDB for MongoDB (architecture autonome) comme source et une instance ApsaraDB for MongoDB (n'importe quelle architecture disponible) comme destination. Le processus de configuration est similaire pour les autres sources de données.

Prérequis

Une instance autonome ApsaraDB for MongoDB source et une instance ApsaraDB for MongoDB de destination ont été créées. Pour plus d'informations, consultez Créer une instance autonome, Créer une instance de jeu de réplicas et Créer une instance de cluster fragmenté.

Remarque
Pour connaître les versions prises en charge, consultez Présentation des solutions de migration.
Nous recommandons que l'espace de stockage de l'instance ApsaraDB for MongoDB de destination soit supérieur de 10 % à l'espace de stockage utilisé par l'instance ApsaraDB for MongoDB source.
Si l'instance ApsaraDB for MongoDB de destination est un cluster fragmenté, vous devez créer les bases de données et les collections nécessitant un fragmentation, configurer le partitionnement des données, activer le répartiteur de charge (Balancer) et pré-découper les chunks dans l'instance ApsaraDB for MongoDB de destination selon vos besoins métier. Pour plus d'informations, consultez Configurer le partitionnement des données pour optimiser les performances des shards et Gérer la distribution inégale des données dans un cluster fragmenté MongoDB.

Remarque
La configuration du partitionnement évite la migration des données vers un seul shard, ce qui permet de maximiser les performances du cluster. L'activation du Balancer et le pré-découpage des chunks aident à prévenir le déséquilibre des données.

Remarques

Type	Description
Limitations de la base de données source	Exigence de bande passante : le serveur de la base de données source doit disposer d'une bande passante sortante suffisante. Sinon, la vitesse de migration des données sera affectée. Les collections à migrer doivent posséder une clé primaire ou une contrainte d'unicité, et les champs contraints doivent contenir des valeurs uniques. Sinon, des données en double peuvent être créées dans la base de données de destination. Les noms de champs dans les données ne doivent pas contenir le caractère « . » (point) ; sinon, des incohérences de données peuvent survenir. Si vous migrez des données au niveau de la collection et devez modifier les collections, par exemple en mappant les noms de collections, une seule tâche de migration peut traiter au maximum 1 000 collections. Si vous dépassez cette limite, la tâche renvoie une erreur lors de la soumission. Dans ce cas, vous devez diviser les collections en plusieurs lots et configurer une tâche distincte pour chaque lot, ou configurer une tâche pour migrer la base de données entière. Un document unique dans la base de données source ne peut pas dépasser 16 Mo. Sinon, la tâche de migration échouera. Limitations opérationnelles sur la base de données source : Pendant les phases de migration du schéma et de migration complète des données, n'effectuez pas de modifications de schéma sur les bases de données ou les collections, y compris la mise à jour des données dans les tableaux. De telles modifications peuvent entraîner l'échec de la migration ou provoquer une incohérence des données entre les bases de données source et de destination. Ce scénario de migration ne prend pas en charge la migration incrémentielle des données. Pour garantir la cohérence des données, n'écrivez pas de nouvelles données dans la base de données MongoDB source pendant la migration complète des données. Si une collection à migrer contient un index TTL (Time-to-Live), une incohérence des données peut survenir ou la latence de l'instance peut augmenter.
Autres limitations	Si l'instance de destination possède une architecture de cluster fragmenté : Vous devez supprimer les documents orphelins, car ils peuvent affecter les performances de la migration. Si des documents présentant des conflits `_id` sont rencontrés pendant la migration, une incohérence des données ou un échec de la tâche peut survenir. Avant de démarrer la tâche, vous devez ajouter une clé de shard aux données source pour chaque collection fragmentée dans la destination. Si vous ne pouvez pas ajouter de clé de shard aux données source, consultez Migrer des données d'une instance MongoDB sans clé de shard vers une instance de cluster fragmenté MongoDB. Une fois la tâche démarrée, la commande INSERT doit inclure la clé de shard. La commande UPDATE ne peut pas modifier la clé de shard. Si l'instance de destination possède une architecture de jeu de réplicas : Lorsque la Access Method est Express Connect, VPN Gateway, or Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN), vous devez définir Domain Name or IP et Port Number sur l'adresse et le port du nœud principal, ou configurer une adresse de connexion haute disponibilité. Pour plus d'informations sur les adresses de connexion haute disponibilité, consultez Créer une instance source ou de destination pour une base de données MongoDB haute disponibilité. Lorsque la Access Method est Self-managed Database on ECS, vous devez définir Port Number sur le port du nœud principal. La migration incrémentielle des données n'est pas prise en charge. DTS ne prend pas en charge la connexion à une base de données MongoDB à l'aide d'un enregistrement SRV. Si la collection de destination possède un index unique ou si son attribut `capped` est défini sur `true`, la collection ne prend pas en charge la relecture simultanée (seule l'écriture monothread est prise en charge) pendant la migration incrémentielle des données. Cela peut augmenter la latence de la tâche. DTS ne prend pas en charge la migration des données depuis les bases de données admin, config ou local. DTS ne conserve pas les informations de transaction. Il convertit les transactions de la base de données source en instructions individuelles dans la base de données de destination. Lorsque DTS écrit des données dans une collection de destination, si un conflit de clé primaire ou de clé unique survient, DTS ignore l'instruction d'écriture des données conflictuelles et conserve les données existantes dans la collection de destination. Maintenez la cohérence des versions MongoDB entre les bases de données source et de destination, ou migrez d'une version antérieure vers une version ultérieure pour garantir la compatibilité. La migration d'une version ultérieure vers une version antérieure peut entraîner des problèmes de compatibilité. Si la base de données source est une version MongoDB antérieure à 3.6 et la base de données de destination est MongoDB 3.6 ou ultérieure, l'ordre des champs dans les données migrées peut différer de celui de la source. Les paires champ-valeur restent correctes. Ceci est dû aux différences dans le plan d'exécution du moteur de base de données. Si la logique de votre application implique une correspondance de texte sur des structures imbriquées, évaluez l'impact potentiel de ce changement d'ordre des champs. Avant de migrer les données, évaluez les performances des bases de données source et de destination et effectuez la migration pendant les heures creuses. Pendant la migration complète des données, DTS consomme des ressources de lecture et d'écriture, ce qui peut augmenter la charge de la base de données. Pendant la migration complète des données, DTS effectue des opérations INSERT concurrentes, ce qui peut provoquer une fragmentation dans les collections de destination. Par conséquent, les collections de destination peuvent occuper plus d'espace de stockage que celles de l'instance source. Vérifiez que la précision de migration utilisée par DTS pour les colonnes FLOAT ou DOUBLE répond à vos besoins métier. DTS lit les valeurs de ces types en utilisant `ROUND(COLUMN,PRECISION)`. Si vous ne définissez pas explicitement la précision, DTS migre les valeurs FLOAT avec une précision de 38 chiffres et les valeurs DOUBLE avec une précision de 308 chiffres. DTS tente de reprendre les tâches de migration échouées dans un délai de sept jours. Avant le basculement du service vers l'instance cible, vous devez terminer ou libérer la tâche, ou utiliser la commande `revoke` pour révoquer les permissions d'écriture du compte utilisé par DTS pour accéder à l'instance cible. Cela empêche les données source d'écraser les données de l'instance cible si la tâche est reprise automatiquement. Étant donné que DTS écrit les données de manière concurrente, la base de données de destination utilise 5 % à 10 % d'espace de stockage supplémentaire par rapport à la base de données source. Utilisez la syntaxe `db.$table_name.aggregate([{ $count:"myCount"}])` pour interroger le nombre dans MongoDB de destination. Assurez-vous que la base de données MongoDB de destination ne contient pas de documents avec la même clé primaire (le champ _id par défaut) que la base de données source. Sinon, une perte de données peut survenir. Si de tels documents existent, supprimez ceux dont les valeurs _id sont conflictuelles de la base de données de destination avant la migration, à condition que cela n'affecte pas votre activité. En cas d'échec d'une tâche, l'équipe support DTS tentera de la restaurer dans un délai de huit heures. Lors de la restauration, elle peut redémarrer la tâche ou ajuster ses paramètres. Remarque Seuls les paramètres de la tâche DTS sont modifiés, et non les paramètres de la base de données. Les paramètres susceptibles d'être ajustés incluent ceux répertoriés dans Modifier les paramètres de l'instance. Si la base de données de destination est un cluster fragmenté MongoDB, après avoir basculé votre activité vers cette base de données, vous devez vous assurer que vos opérations métier respectent ses exigences pour les collections fragmentées. Vous ne pouvez pas migrer des `collections capped` lorsque la base de données source est MongoDB 5.0 ou ultérieure et la base de données de destination est une version antérieure. Cela peut entraîner l'échec de la tâche ou une incohérence des données. En effet, le comportement des `collections capped` a changé dans MongoDB 5.0, autorisant les suppressions explicites et l'augmentation de la taille des documents lors des mises à jour. Les noyaux de base de données antérieurs ne sont pas compatibles avec ces fonctionnalités. Les collections de séries temporelles, introduites dans MongoDB 5.0, ne sont pas prises en charge pour la migration.
Cas particulier	Si la source est une base de données MongoDB auto-gérée, un basculement primaire/secondaire pendant la migration entraînera l'échec de la tâche.

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.

Types de migration

Type	Description
Migration du schéma	Migre les schémas d'objets de l'instance ApsaraDB for MongoDB source vers l'instance ApsaraDB for MongoDB de destination. Remarque La migration du schéma prend en charge les bases de données, les collections et les index.
Migration complète des données	Migre toutes les données existantes de l'instance ApsaraDB for MongoDB source vers l'instance ApsaraDB for MongoDB de destination. Remarque La migration complète des données prend en charge les bases de données et les collections.

Permissions des comptes de base de données

Base de données	Migration du schéma	Migration complète
Instance ApsaraDB for MongoDB source	Permissions de lecture sur la base de données à migrer et sur la base de données config.
Instance ApsaraDB for MongoDB de destination	Permission dbAdminAnyDatabase, permissions de lecture et d'écriture sur la base de données de destination, et permissions de lecture sur la base de données local.

Pour créer des comptes de base de données et accorder des permissions aux instances ApsaraDB for MongoDB source et de destination, consultez Gérer les permissions utilisateur sur les bases de données MongoDB.

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 en fonction du mode et de 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 de la tâche.

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 des incohérences de données pourraient survenir.

Catégorie	Paramètre	Description
N/A	Task Name	DTS génère automatiquement un nom de tâche. Nous vous recommandons de spécifier un nom descriptif pour une identification facile. Le nom n'a pas besoin d'être unique.
Source Database	Select Existing Connection	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 MongoDB.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région de l'instance ApsaraDB for MongoDB 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.
	Architecture	Pour une instance MongoDB autonome, sélectionnez Replica Set. Replica Set : Une instance de jeu de réplicas déploie plusieurs types de nœuds pour atteindre la haute disponibilité et la séparation lecture/écriture. Pour plus d'informations, consultez Architecture de jeu de réplicas. Sharded Cluster : Une instance de cluster fragmenté se compose de trois composants : mongos, shard et ConfigServer. Vous pouvez personnaliser le nombre et les configurations des nœuds mongos et shard. Pour plus d'informations, consultez Architecture de cluster fragmenté.
	Migration Method	La migration incrémentielle n'est pas prise en charge lorsque la base de données source est une instance MongoDB autonome. Conservez la valeur par défaut Oplog.
	Instance ID	Sélectionnez l'ID de l'instance ApsaraDB for MongoDB source.
	Authentication Database	Saisissez le nom de la base de données à laquelle appartient le compte de base de données de l'instance ApsaraDB for MongoDB source. La valeur par défaut est admin.
	Database Account	Saisissez le compte de base de données de l'instance ApsaraDB for MongoDB source. Pour obtenir des 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.
	Encryption	DTS prend en charge trois méthodes de connexion : Non-encrypted, SSL-encrypted et Mongo Atlas SSL. Les options de Encryption varient en fonction de la Access Method et de l'Architecture sélectionnées. Les options affichées dans la console font foi. Remarque Une base de données MongoDB dont l'Architecture est Sharded Cluster et dont la Migration Method est Oplog ne prend pas en charge le SSL-encrypted. Si la source est une base de données MongoDB auto-gérée (la Access Method n'est pas Alibaba Cloud Instance) avec une architecture Replica Set, et que vous sélectionnez SSL-encrypted, DTS vous permet également de télécharger un certificat CA pour vérifier la connexion.
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 MongoDB.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région de l'instance ApsaraDB for MongoDB de destination.
	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.
	Architecture	Sélectionnez une architecture en fonction de vos besoins métier. Valeurs valides : Replica Set : Une instance de jeu de réplicas déploie plusieurs types de nœuds pour atteindre la haute disponibilité et la séparation lecture/écriture. Pour plus d'informations, consultez Architecture de jeu de réplicas. Sharded Cluster : Une instance de cluster fragmenté se compose de trois composants : mongos, shard et ConfigServer. Vous pouvez personnaliser le nombre et les configurations des nœuds mongos et shard. Pour plus d'informations, consultez Architecture de cluster fragmenté.
	Instance ID	Sélectionnez l'ID de l'instance ApsaraDB for MongoDB de destination.
	Authentication Database	Saisissez le nom de la base de données à laquelle appartient le compte de base de données de l'instance ApsaraDB for MongoDB de destination. La valeur par défaut est admin.
	Database Account	Saisissez le compte de base de données de l'instance ApsaraDB for MongoDB de destination. Pour obtenir des 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.
	Encryption	DTS prend en charge trois méthodes de connexion : Non-encrypted, SSL-encrypted et Mongo Atlas SSL. Les options de Encryption varient en fonction de la Access Method et de l'Architecture sélectionnées. Les options affichées dans la console font foi. Remarque Les bases de données MongoDB avec une Architecture de Sharded Cluster ne prennent pas en charge le SSL-encrypted. Si la destination est une base de données MongoDB auto-gérée (la Access Method n'est pas Alibaba Cloud Instance) avec un Replica Set, et que vous sélectionnez SSL-encrypted, DTS vous permet également de télécharger un certificat CA pour vérifier la connexion.

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 pour autoriser l'accès depuis les serveurs DTS. Pour plus d'informations, consultez Ajouter les adresses IP des serveurs DTS à une liste blanche.
- Si la base de données source ou de destination est une base de données auto-gérée (la 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.

Configurez les objets de la tâche.

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

Paramètre	Description
Migration Types	Sélectionnez à la fois Schema Migration et Full Data Migration. Remarque Ce scénario ne prend pas en charge la migration incrémentielle. Pour garantir la cohérence des données, n'écrivez pas de nouvelles données dans l'instance source pendant la migration des données. Pour plus d'informations, consultez Types de migration.
Processing Mode of Conflicting Tables	Precheck and Report Errors : Vérifie si des collections portant les mêmes noms existent dans la base de données de destination. Si aucune collection portant les mêmes noms n'existe, le précontrôle est réussi. Si des collections portant les mêmes noms existent, une erreur est signalée lors du précontrôle et la tâche de migration des données ne démarre pas. Remarque Si une collection dans 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 collection dans la base de données de destination. Pour plus d'informations, consultez Mappage des noms d'objets. Ignore Errors and Proceed : Ignore la vérification des collections portant les mêmes noms. Avertissement La sélection de l'option Ignore Errors and Proceed peut entraîner une incohérence des données et des risques métier. Par exemple : Si un enregistrement dans la base de données de destination possède la même valeur de clé primaire qu'un enregistrement dans la base de données source, l'enregistrement dans la base de données de destination est conservé. L'enregistrement de la base de données source n'est pas migré vers la base de données de destination. L'initialisation des données peut échouer, seules certaines données peuvent être migrées ou la migration peut échouer.
Capitalization of Object Names in Destination Instance	Vous pouvez spécifier la sensibilité à la casse pour les noms des bases de données et des collections migrées dans l'instance de destination. Par défaut, la DTS default policy est sélectionnée. Vous pouvez également sélectionner une stratégie cohérente avec la stratégie 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 destination.
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 Vous pouvez sélectionner des objets au niveau de la base de données ou de la collection.
Selected Objects	Pour définir le nom d'un objet de migration dans l'instance de destination, ou pour spécifier l'objet qui reçoit les données dans l'instance de destination, faites un clic droit sur l'objet de migration dans la zone Selected Objects pour effectuer des modifications. Pour plus d'informations, consultez Mappage des noms d'objets. Pour supprimer un objet de migration sélectionné, cliquez sur l'objet dans la zone Selected Objects, puis cliquez sur pour le déplacer vers la zone Source Objects. Remarque Pour filtrer les données en fonction de conditions, ce qui est pris en charge lors de la migration complète des données, faites un clic droit sur la collection à migrer dans la zone Selected Objects et configurez les paramètres dans la boîte de dialogue qui s'affiche. Pour plus d'informations, consultez Définir les conditions de filtre. Si vous utilisez la fonctionnalité de mappage des noms d'objets pour spécifier une base de données ou une collection qui reçoit les données, la migration d'autres objets dépendant de l'objet mappé peut échouer.

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

Paramètre	Description
Dedicated Cluster for Task Scheduling	Par défaut, DTS planifie les tâches sur un cluster partagé. Vous n'avez pas besoin d'en sélectionner un. Si vous souhaitez des tâches plus stables, vous pouvez acheter un cluster dédié pour exécuter les tâches de migration DTS.
Retry Time for Failed Connections	Une fois la tâche de migration démarrée, si la connexion à la base de données source ou de destination échoue, DTS signale une erreur et commence immédiatement à retenter la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser la durée de nouvelle tentative à une valeur comprise entre 10 et 1440 minutes. Nous vous recommandons de définir la durée à plus de 30 minutes. Si DTS se reconnecte aux bases 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 la même destination, la durée de nouvelle tentative réseau est déterminée par le paramètre de la dernière tâche créée. Étant donné que la tâche vous est facturée pendant la période de nouvelle tentative de connexion, nous vous recommandons de personnaliser la durée de nouvelle tentative en fonction de vos besoins métier, ou de libérer l'instance DTS dès que possible après la libération des instances de base de données source et de destination.
Retry Time for Other Issues	Une fois la tâche de migration démarrée, si un problème autre que de connectivité, tel qu'une exception d'exécution DDL ou DML, survient dans la base de données source ou de destination, DTS signale une erreur et commence immédiatement à retenter l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser la durée de nouvelle tentative à une valeur comprise entre 1 et 1440 minutes. Nous vous recommandons de définir la durée à plus de 10 minutes. Si les opérations connexes réussissent dans la durée de nouvelle tentative spécifiée, la tâche de migration reprend automatiquement. Sinon, la tâche échoue. Important La valeur de Retry Time for Other Issues doit être inférieure à la valeur de Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Pendant la migration complète, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui peut augmenter la charge de la base de données. Si nécessaire, vous pouvez activer la limitation pour la tâche de migration complète. Vous pouvez définir les Queries per second (QPS) to the source database, les RPS of Full Data Migration et la Data migration speed for full migration (MB/s) afin de réduire la charge sur la base de données de destination. Remarque Cet élément de configuration est disponible uniquement si vous sélectionnez Full Data Migration pour les Migration Types. Vous pouvez également ajuster la vitesse de migration complète une fois l'instance de migration en cours d'exécution.
Only one data type for primary key _id in a table of the data to be synchronized	Dans les données à migrer, le type de données de la clé primaire `_id` est-il uniforme au sein d'une seule collection ? Important Sélectionnez une option en fonction de vos besoins. Sinon, une perte de données peut survenir. Ce paramètre est disponible uniquement si vous sélectionnez Full Data Migration pour les Migration Types. Yes : Le type de données est unique. Pendant la migration complète des données, DTS n'analyse pas les types de données des clés primaires dans les données source. Pour une seule collection, DTS migre uniquement les données correspondant à un type de données de clé primaire. No : Le type de données n'est pas unique. Pendant la migration complète des données, DTS analyse les types de données des clés primaires dans les données source et migre toutes les données.
Environment Tag	Vous pouvez sélectionner un tag d'environnement pour identifier l'instance. Aucun tag n'est nécessaire dans cet exemple.
Configure ETL	En fonction de vos besoins métier, sélectionnez si vous souhaitez configurer la fonctionnalité ETL pour traiter les données. Yes : Configure la fonctionnalité ETL. Vous devez également saisir les instructions de traitement des données dans la zone de texte. No : Ne configure pas la fonctionnalité ETL.
Monitoring and Alerting	Sélectionnez si vous souhaitez définir des alertes et recevoir des notifications d'alerte en fonction de vos besoins métier. No : Ne définit pas d'alerte. Yes : Configurez les alertes en définissant un seuil d'alerte et un notifications d'alerte. Si une migration échoue ou si la latence dépasse le seuil, le système envoie une notification d'alerte.

Cliquez sur Next Data Verification pour configurer une tâche de vérification des données.

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

Enregistrez la tâche et exécutez un précontrôle.
- Pour afficher les paramètres de configuration de cette instance lors de l'appel de l'opération API, placez le pointeur sur le bouton Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters dans la bulle qui s'affiche.
- Si vous n'avez pas besoin d'afficher ou avez terminé d'afficher les paramètres API, cliquez sur Next: Save Task Settings and Precheck en bas de la page.
Remarque
- Avant le démarrage de la tâche de migration, DTS effectue un précontrôle. La tâche ne démarre qu'après avoir réussi le précontrôle.
- Si le précontrôle échoue, cliquez sur View Details à côté de l'élément de vérification ayant échoué, corrigez le problème selon l'invite, puis exécutez à nouveau le précontrôle.
- Si un avertissement est signalé lors du précontrôle :
  
  Pour les éléments de vérification qui ne peuvent pas être ignorés, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème selon l'invite, puis exécutez à nouveau le précontrôle.
  
  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 exécuter à nouveau le précontrôle. 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é.

Achetez l'instance.

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

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

Catégorie	Paramètre	Description
New Instance Class	Resource Group Settings	Sélectionnez le groupe de ressources auquel appartient l'instance. 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 liaison affecte la vitesse de migration. Vous pouvez sélectionner une spécification en fonction de votre scénario métier. Pour plus d'informations, consultez Spécifications de liaison de migration de données.

Une fois la configuration terminée, lisez et sélectionnez 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. Tant que la tâche de migration incrémentielle est en cours d'exécution, le Status de la tâche est Running.