Migrer un cluster shardé MongoDB auto-géré vers ApsaraDB à l'aide de DTS - ApsaraDB for MongoDB

Migrez un cluster shardé MongoDB auto-géré vers ApsaraDB for MongoDB, shard par shard, en utilisant Data Transmission Service (DTS). La migration incrémentielle de DTS permet de maintenir votre application en cours d'exécution pendant la migration.

Pour d'autres options, consultez Présentation des solutions de migration et de synchronisation des données MongoDB.

Prérequis

Vérifiez que les versions de vos instances MongoDB source et destination sont prises en charge. Consultez les combinaisons de versions prises en charge dans Solutions de migration.

ta-tag="xref" id="xref_78n_86r_96y" href="t17092.dita#concept_26618_zh">Migration solutions.
Assurez-vous que chaque shard de l'instance de cluster shardé de destination dispose d'un espace de stockage suffisant.

Remarque
Exemple : Si le plus grand shard de votre base de données source utilise 500 Go, chaque shard de l'instance de destination doit disposer de plus de 500 Go de stockage.

your source database uses 500 GB, each shard in the destination instance must have more than 500 GB of storage.

Fonctionnement

DTS migre un cluster shardé shard par shard. Créez une tâche de migration distincte pour chaque shard.

Remarque

La distribution des données dépend de la clé de shard que vous configurez. Configurer le sharding des données pour optimiser les performances des shards.

Migration architecture

Notes d'utilisation

La migration complète des données augmente la charge sur les bases de données source et destination. Exécutez la migration pendant les heures creuses pour éviter toute interruption de service.

avoid service interruptions.
Lors d'une migration entre différentes versions ou moteurs de stockage, vérifiez d'abord la compatibilité dans Versions et moteurs de stockage.

a#concept_qg2_xcr_52b">Versions and storage engines first.
DTS écrit les données de manière concurrente ; par conséquent, la base de données de destination peut utiliser 5 % à 10 % d'espace de stockage supplémentaire par rapport à la source.

database may use 5 % to 10 % more storage than the source.
Assurez-vous que la destination ne contient aucun document ayant la même clé primaire (_id par défaut) que la source. Si des conflits existent et que leur suppression n'affecte pas votre activité, supprimez les documents conflictuels de la destination avant la migration.

nflicts exist and deletion does not affect your business, delete the conflicting documents from the destination before migration.
Les bases de données admin et local ne peuvent pas être utilisées comme source ou destination.

cannot be used as the source or destination.
Le cluster shardé MongoDB source peut comporter au maximum 10 nœuds mongos.

have a maximum of 10 mongos nodes.

Facturation

Type de migration	Frais de configuration de la tâche	Frais de trafic Internet
Migration complète des données	Gratuit.	Les données migrées hors d'Alibaba Cloud via l'Internet public sont facturées. Tarification DTS.
Migration incrémentielle des données	Facturé. .Tarification DTS

Types de migration

Migration complète des données : Copie toutes les données existantes des objets source sélectionnés vers la destination.

Remarque
Inclut les bases de données, les collections et les index.

n1y_f19">

Includes databases, collections, and indexes.
Migration incrémentielle des données : Une fois la migration complète terminée, DTS synchronise continuellement les modifications de données de la source vers la destination.
Remarque
- DTS synchronise les opérations de création et de suppression pour les bases de données, les collections et les index.
- DTS synchronise les opérations de création, de suppression et de mise à jour pour les documents.
and delete operations for databases, collections, and indexes. ns for databases, collections, and indexes.
DTS synchronizes create, delete, and update operations for documents.

te, and update operations for documents.

Autorisations des comptes de base de données

Base de données

Migration complète des données

Migration incrémentielle des données

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

Autorisation read sur les bases de données à migrer.

Autorisation read sur les bases de données à migrer, ainsi que sur les bases de données admin et local.

Instance ApsaraDB for MongoDB

Autorisation readWrite sur la base de données de destination.

Pour créer des comptes de base de données et accorder des autorisations :

MongoDB auto-géré : db.createUser() (documentation MongoDB).

ngoDB documentation).
ApsaraDB for MongoDB : Gérer les utilisateurs d'une base de données MongoDB à l'aide de DMS.

goDB database by using DMS.

Avant de commencer

Requis : Désactivez l'équilibreur de charge (balancer) pendant la migration pour éviter les incohérences de données. Gérer l'équilibreur de charge d'une instance MongoDB.

Avertissement
Si l'équilibreur de charge n'est pas désactivé, les migrations de chunks peuvent affecter la cohérence des données lues par DTS.

"c43899c026iua">If the balancer is not disabled, chunk migrations can affect the consistency of the data DTS reads.

Supprimez les documents orphelins créés par les échecs de migration de chunks de la base de données source.

Remarque

Les documents orphelins peuvent dégrader les performances de migration et provoquer des conflits _id entraînant des erreurs.

Téléchargez le script cleanupOrphaned.js.

wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

Dans le script cleanupOrphaned.js, remplacez test par le nom de la base de données à nettoyer.

Remarque

Si vous avez plusieurs bases de données, répétez cette étape et l'étape c.

function cleanupOrphaned(coll) {
  var nextKey = { };
  var result;
  while ( nextKey != null ) {
    result = db.adminCommand( { cleanupOrphaned: coll, startingFromKey: nextKey } );
    if (result.ok != 1)
      print("Unable to complete at this time: failure or timeout.")
    printjson(result);
    nextKey = result.stoppedAtKey;
  }
}
var dbName = 'test'
db = db.getSiblingDB(dbName)
db.getCollectionNames().forEach(function(collName) {
        cleanupOrphaned(dbName + "." + collName);
});

Exécutez cette commande sur chaque shard pour supprimer les documents orphelins de toutes les collections de la base de données.

Remarque

À exécuter sur chaque shard.

mongo --host <Shardhost> --port <Primaryport>  --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js

Remarque

<Shardhost> : L'adresse IP du shard.
<Primaryport> : Le port de service du nœud principal du shard.
<database> : La base de données d'authentification pour le compte.
<username> : Le compte de base de données.
<password> : Le mot de passe du compte.

Exemple avec trois shards :

mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

d826nfg"><password>: The account password.

Example with three shards:

mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

g="codeblock" id="codeblock_6ze_gis_zmv" outputclass="language-plaintext" code-type="xCode">mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

Créez les bases de données et les collections nécessitant un sharding dans l'instance de destination, et configurez le sharding des données. Configurer le sharding des données pour optimiser les performances des shards.

Remarque

La configuration du sharding avant la migration empêche toutes les données d'être stockées sur un seul shard et de dépasser sa capacité de stockage.

ote" id="note_keh_seo_9uz">

Configuring sharding before migration prevents all data from landing on a single shard and exceeding its storage capacity.

Limites

Limites de la base de données source

Le serveur doit disposer d'une bande passante sortante suffisante. Une bande passante insuffisante ralentit la migration.
Les collections à migrer doivent avoir des contraintes de CLÉ PRIMAIRE ou UNIQUE, avec tous les champs uniques. Sinon, des doublons peuvent apparaître dans la destination.
DTS utilise les ressources de lecture et d'écriture sur les bases de données source et destination pendant la migration complète des données, ce qui augmente la charge du serveur. Exécutez les migrations pendant les heures creuses.
Si les bases de données source et destination utilisent des versions MongoDB ou des moteurs de stockage différents, vérifiez d'abord la compatibilité. Consultez Versions MongoDB et moteurs de stockage.
Pour la migration incrémentielle des données, activez l'oplog sur la base de données source et conservez l'oplog pendant au moins 7 jours. Si l'oplog n'est pas activé, des messages d'erreur sont renvoyés lors de la pré-vérification et la tâche de migration des données ne peut pas démarrer. Si DTS ne peut pas obtenir l'oplog, la tâche échoue et une incohérence ou une perte de données peut survenir. Ces exigences de rétention ne relèvent pas de l'accord de niveau de service (SLA) de DTS.
Si vous sélectionnez des collections comme objets de migration et prévoyez de les modifier dans la destination (par exemple, les renommer), une seule tâche prend en charge jusqu'à 1 000 collections. Pour plus de 1 000 collections, configurez plusieurs tâches ou migrez la base de données entière.
N'utilisez pas la base de données admin ou local comme source ou destination.
La base de données MongoDB auto-gérée source ne peut pas avoir plus de 10 nœuds mongos.
Ne migrez pas de collections avec des index TTL (Time To Live). Les index TTL peuvent provoquer des incohérences de données entre la source et la destination après la migration.
Assurez-vous qu'aucun document orphelin n'existe dans la base de données source ou l'instance de cluster shardé de destination. Les documents orphelins peuvent provoquer des incohérences de données ou l'échec de la tâche. Consultez la documentation MongoDB et Comment supprimer les documents orphelins d'une base de données MongoDB déployée dans une architecture de cluster shardé ?.

Pendant la migration, n'exécutez pas les commandes suivantes sur la base de données source — elles modifient la distribution des données et provoquent des incohérences :

shardCollection, reshardCollection, unshardCollection, moveCollection, movePrimary

Pendant la migration du schéma et la 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 types de tableau. Les modifications de schéma provoquent l'échec de la tâche ou des incohérences de données.
N'écrivez pas de données dans la base de données source si vous exécutez uniquement la migration complète des données (sans migration incrémentielle). Pour garantir la cohérence des données, sélectionnez conjointement la migration du schéma, la migration complète des données et la migration incrémentielle des données.

Si l'équilibreur de charge de la base de données source est actif pendant la migration, la migration des chunks peut introduire de la latence.

Autres limites

Si vous achetez une instance DTS avant de configurer une tâche, spécifiez le nombre de shards au moment de l'achat.
DTS ne peut pas se connecter à une base de données MongoDB via une chaîne de connexion SRV.
Ajoutez des clés de shard à toutes les données de la base de données source avant de démarrer la migration. Pendant la migration, les opérations INSERT doivent inclure les clés de shard, et les opérations UPDATE ne peuvent pas modifier les clés de shard.
Désactivez l'équilibreur de charge pour la base de données MongoDB source pendant la migration complète des données. Maintenez-le désactivé jusqu'à ce que chaque sous-tâche atteigne la phase de migration incrémentielle des données. Le réactiver prématurément provoque des incohérences de données. Consultez Gérer l'équilibreur de charge ApsaraDB for MongoDB.
Assurez-vous que la base de données de destination ne contient pas déjà de documents ayant la même clé primaire (_id) que la source. Si des doublons existent, supprimez les documents correspondants dans la destination avant de démarrer la migration.
Les informations de transaction ne sont pas conservées. Les transactions migrées sont converties en enregistrements individuels.
Si un conflit de clé primaire ou de clé unique se produit lorsque DTS écrit dans la destination, DTS ignore l'écriture conflictuelle et conserve les données existantes.
Ne mettez pas à l'échelle une instance de cluster shardé ApsaraDB for MongoDB pendant l'exécution d'une tâche de migration. La mise à l'échelle provoque l'échec de la tâche.
Interrogez les résultats de comptage sur la base de données ApsaraDB for MongoDB de destination en utilisant db.$table_name.aggregate([{ $count:"myCount"}]).
Étant donné que DTS écrit les données de manière concurrente, l'espace de stockage utilisé dans la destination est 5 à 10 % plus grand que dans la source.
Si une collection de destination possède un index unique ou si l'attribut capped est défini sur true, la collection ne prend en charge que les écritures mono-thread et ne prend pas en charge la relecture concurrente pendant la migration incrémentielle. Cela peut augmenter la latence de migration.
La migration complète des données utilise les ressources de lecture et d'écriture sur les deux bases de données, augmentant la charge du serveur. Exécutez les migrations pendant les heures creuses.
Les opérations INSERT concurrentes pendant la migration complète des données provoquent une fragmentation des tables. Après la migration complète des données, l'espace tablespace dans la destination est plus grand que dans la source.
DTS tente de reprendre les tâches de migration échouées pendant 7 jours maximum. Avant de basculer les charges de travail vers l'instance de destination, arrêtez ou libérez toutes les tâches échouées, ou révoquez les autorisations d'écriture de DTS sur la destination. Sinon, les données source écraseront les données de destination lorsqu'une tâche échouée reprendra.
Si une tâche DTS échoue, l'assistance technique DTS tente de la restaurer dans un délai de 8 heures. Pendant la restauration, la tâche peut redémarrer et les paramètres de la tâche peuvent être modifiés.

Seuls les paramètres de la tâche peuvent être modifiés — les paramètres de la base de données ne sont pas changés. Les paramètres susceptibles d'être modifiés sont répertoriés dans la section Modifier les paramètres de l'instance .
Si la destination est une instance de jeu de réplicas :
- Si connecté via Express Connect, VPN Gateway, Smart Access Gateway, adresse IP publique ou Cloud Enterprise Network (CEN) : définissez Domain Name or IP et Port Number
  
  à l'adresse IP et au port du nœud principal, ou configurez un endpoint haute disponibilité. Consultez Créer une tâche DTS où la base de données source ou de destination est une base de données MongoDB haute disponibilité
- Si connecté via Self-managed Database on ECS : définissez Port Number sur le port du nœud principal.
Si la destination est une instance de cluster shardé, assurez-vous que le comportement de votre application répond aux exigences du cluster shardé ApsaraDB for MongoDB.

Migrer les données

Avant de commencer

Effectuez les étapes suivantes avant de créer la tâche DTS.

Étape 1 : Désactiver l'équilibreur de charge de la base de données source

Désactivez l'équilibreur de charge sur la base de données MongoDB auto-gérée pour empêcher la migration de chunks d'affecter la cohérence des données pendant la tâche DTS.

Avertissement

Si l'équilibreur de charge est actif pendant la migration, la migration de chunks amène DTS à lire des données incohérentes.

Pour les instructions, consultez Gérer l'équilibreur de charge ApsaraDB for MongoDB.

Étape 2 : Supprimer les documents orphelins de la base de données source

Les documents orphelins laissés par les échecs de migration de chunks compromettent les performances de migration, peuvent créer des valeurs _id en double et peuvent entraîner la migration de données indésirables.

Téléchargez le fichier cleanupOrphaned.js :

wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

Dans le fichier cleanupOrphaned.js, remplacez test par le nom de la base de données dont vous souhaitez supprimer les documents orphelins.

Pour supprimer les documents orphelins de plusieurs bases de données, répétez cette étape et l'étape suivante pour chaque base de données.

Exécutez la commande suivante sur chaque shard pour supprimer les documents orphelins de toutes les collections de la base de données spécifiée :

Exécutez cette commande sur chaque shard.

Paramètre

Description

<Shardhost>

Adresse IP du shard

<Primaryport>

Port de service du nœud principal du shard

<database>

Nom de la base de données à laquelle appartient le compte

<username>

Compte utilisé pour se connecter à la base de données MongoDB auto-gérée

<password>

Mot de passe utilisé pour se connecter à la base de données MongoDB auto-gérée

mongo --host <Shardhost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js

Exemple : Pour une base de données source avec trois shards :

mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

Étape 3 : Configurer le sharding dans l'instance de destination (cluster shardé uniquement)

Si la destination est une instance de cluster shardé, créez les bases de données et les collections à sharder, puis configurez le sharding des données avant de démarrer la migration. Cette procédure permet de répartir uniformément les données migrées entre les shards et d'éviter la surcharge d'un shard unique.

Consultez la rubrique Configurer le sharding pour optimiser les performances des shards.

Étape 1 : Accéder à la page Data Migration

Utilisez l'une des méthodes suivantes pour ouvrir la page Data Migration et sélectionnez la région où réside l'instance de migration.

Console DTS

Connectez-vous à la console DTS.
Dans le volet de navigation de gauche, cliquez sur Data Migration.
Dans le coin supérieur gauche, sélectionnez la région où réside l'instance de migration de données.

Console DMS

Les étapes exactes peuvent varier en fonction du mode et de la disposition de la console DMS. Consultez les rubriques Simple mode et Customize the layout and style of the DMS console .

Connectez-vous à la console DMS.
Dans la barre de navigation supérieure, accédez à Data + AI > DTS (DTS) > Data Migration.
Dans la liste déroulante située à droite de Data Migration Tasks, sélectionnez la région où réside l'instance de migration.

Étape 2 : Créer une tâche

Cliquez sur Create Task pour accéder à la page de configuration de la tâche.

Étape 3 : Configurer les bases de données source et de destination

Avertissement

Après avoir configuré les bases de données source et de destination, lisez attentivement la section Limits affichée en haut de la page. Ignorer cette étape peut entraîner l'échec de la tâche ou provoquer des incohérences de données.

Configurez les paramètres suivants :

General

Parameter

Description

Task Name

DTS génère automatiquement un nom de tâche. Spécifiez un nom descriptif pour faciliter l'identification de la tâche. Un nom unique n'est pas requis.

Source database

Parameter

Description

Select Existing Connection

Si l'instance est enregistrée auprès de DTS, sélectionnez-la dans la liste déroulante ; DTS renseignera automatiquement les autres paramètres. Sinon, configurez manuellement les paramètres ci-dessous. Dans la console DMS, effectuez votre sélection dans la liste Select a DMS database instance.

Database Type

Sélectionnez MongoDB.

Access Method

Sélectionnez la méthode de connexion. Cet exemple utilise Public IP Address. Pour les autres méthodes, configurez préalablement l'environnement réseau. Consultez la rubrique Preparation overview.

Instance Region

La région où réside la base de données source. Si la région ne figure pas dans la liste, sélectionnez la plus proche géographiquement.

Architecture

Sélectionnez Sharded Cluster. Cette option n'apparaît que pour les méthodes d'accès Express Connect, VPN Gateway, Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN).

Migration Method

Sélectionnez la méthode de migration des données incrémentielles : Oplog (recommandé) ou ChangeStream. L'option Oplog est disponible lorsque l'oplog est activé sur la source (activé par défaut sur les bases de données gérées en interne et les instances ApsaraDB for MongoDB) et offre une migration incrémentielle à faible latence. L'option ChangeStream est disponible lorsque les change streams sont activés. Consultez la documentation Change Streams. Si la source est un cluster Amazon DocumentDB non élastique, sélectionnez uniquement ChangeStream. Si le paramètre Architecture est défini sur Sharded Cluster, les paramètres Shard account et Shard password ne sont pas requis.

Endpoint Type

Sélectionnez Standalone ou Multi-node selon votre configuration. Ce paramètre n'apparaît que pour les méthodes d'accès Express Connect, VPN Gateway, Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN).

Mongos Domain Name or IP Address

L'endpoint ou l'adresse IP de n'importe quel nœud mongos. Ce champ apparaît uniquement lorsque le paramètre Endpoint Type est défini sur Standalone. Définissez le paramètre Domain Name or IP avec l'adresse d'un nœud mongos et le paramètre Port Number avec son port.

Port Number

Le port de service du nœud mongos. Ce champ apparaît uniquement lorsque le paramètre Endpoint Type est défini sur Standalone. Le port doit être accessible via Internet.

Mongos endpoint

L'endpoint de la base de données source au format <IP>:<Port>. Ce champ apparaît uniquement lorsque le paramètre Endpoint Type est défini sur Multi-node. Séparez les différents endpoints par des sauts de ligne. Utilisez de préférence un nom de domaine accessible publiquement.

Authentication Database

La base de données d'authentification pour la source. Valeur par défaut : admin.

Database Account

Le compte permettant d'accéder aux nœuds mongos. Si la méthode Access Method est définie sur Self-managed Database on ECS ou Database Gateway, saisissez plutôt le compte d'accès aux shards.

Database Password

Le mot de passe du compte de base de données.

Access to Multiple Shard Nodes

Les informations d'accès aux nœuds de shard. Disponible uniquement lorsque l'architecture source est Sharded Cluster, que la méthode Migration Method est Oplog et que le type Endpoint Type est Multi-node. Cliquez sur Add, saisissez l'endpoint de chaque nœud de shard au format <IP>:<Port> (un par ligne) et répétez l'opération pour tous les shards.

Shard access information (IP:Port)

L'adresse IP et le port de chaque shard, au format IP:Port. Ce champ apparaît uniquement lorsque le paramètre Endpoint Type est défini sur Standalone. Séparez les différents shards par des virgules.

Shard account

Le compte permettant d'accéder aux shards dans la base de données source.

Shard password

Le mot de passe du compte de shard.

Encryption

La méthode de chiffrement de la connexion : Non-encrypted, SSL-encrypted ou Mongo Atlas SSL. Les options disponibles dépendent des paramètres Access Method et Architecture. Si l'option Architecture est définie sur Sharded Cluster et que la méthode Migration Method est Oplog, l'option SSL-encrypted n'est pas disponible pour ApsaraDB for MongoDB. Si la source utilise une architecture Replica Set, que la méthode Access Method n'est pas Alibaba Cloud Instance et que l'option Encryption est SSL-encrypted, téléchargez un certificat CA pour vérifier la connexion.

Destination database

Parameter

Description

Select Existing Connection

Si l'instance est enregistrée auprès de DTS, sélectionnez-la dans la liste déroulante. Sinon, configurez les paramètres ci-dessous.

Database Type

Sélectionnez MongoDB.

Access Method

Sélectionnez Alibaba Cloud Instance.

Instance Region

La région où réside l'instance ApsaraDB for MongoDB de destination.

Replicate Data Across Alibaba Cloud Accounts

Sélectionnez No pour utiliser une instance appartenant au compte actuel.

Architecture

L'architecture de l'instance de destination.

Instance ID

L'ID de l'instance ApsaraDB for MongoDB de destination.

Authentication Database

La base de données d'authentification pour la destination. Valeur par défaut : admin.

Database Name

Le nom de la base de données de destination qui recevra les objets migrés.

Database Account

Le compte de base de données pour l'instance de destination.

Database Password

Le mot de passe du compte de la base de données de destination.

Encryption

La méthode de chiffrement de la connexion. Les options disponibles dépendent des paramètres Access Method et Architecture. Si la destination est une instance ApsaraDB for MongoDB avec une architecture Sharded Cluster, l'option SSL-encrypted n'est pas disponible.

Étape 4 : Tester la connectivité

Cliquez sur Test Connectivity and Proceed.

Assurez-vous que les blocs CIDR des serveurs DTS ont été ajoutés aux paramètres de sécurité des bases de données source et de destination. Consultez la rubrique Add the CIDR blocks of DTS servers . Si la source ou la destination est une base de données gérée en interne non connectée en tant qu' Alibaba Cloud Instance , cliquez sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .

Étape 5 : Configurer les objets de migration

Sur la page Configure Objects , configurez les paramètres suivants :

Parameter

Description

Migration Types

Sélectionnez les types de migration selon vos besoins. Pour effectuer uniquement une migration complète des données, sélectionnez Schema Migration et Full Data Migration. Pour maintenir le service actif pendant la migration, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration. Si l'option Schema Migration n'est pas sélectionnée, créez la base de données et les collections dans la destination avant de démarrer la tâche, et activez le mappage des noms d'objets dans la section Selected Objects. Si l'option Incremental Data Migration n'est pas sélectionnée, n'écrivez aucune donnée dans la source pendant la migration.

Processing Mode of Conflicting Tables

Precheck and Report Errors : vérifie si la destination contient des collections portant les mêmes noms que celles de la source. La vérification préalable échoue en cas de doublons. Pour résoudre les conflits de nommage sans supprimer ni renommer les collections de destination, utilisez la fonctionnalité de mappage des noms d'objets. Consultez la rubrique Map object names. Ignore Errors and Proceed : ignore la vérification préalable des noms de collections en double. Lors de la migration complète des données, si un enregistrement possède la même clé primaire qu'un enregistrement existant dans la destination, l'enregistrement existant est conservé. Lors de la migration incrémentielle des données, l'enregistrement existant est écrasé. Si les schémas source et destination diffèrent, certaines colonnes peuvent ne pas être migrées.

Capitalization of Object Names in Destination Instance

Contrôle la casse des noms de bases de données et de collections dans la destination. Valeur par défaut : DTS default policy. Consultez la rubrique Specify the capitalization of object names in the destination instance.

Source Objects

Sélectionnez un ou plusieurs objets (collections ou bases de données), puis cliquez sur l'icône 向右小箭头 pour les ajouter à la section Selected Objects.

Selected Objects

Cliquez avec le bouton droit sur un objet pour le renommer dans la destination ou le mapper vers un autre objet de destination. Consultez la rubrique Map object names. Cliquez avec le bouton droit sur un objet pour définir le mode de migration incrémentielle pour les bases de données et les collections. Cliquez avec le bouton droit sur une collection pour spécifier les conditions de filtre WHERE pour la migration complète. Consultez la rubrique Specify filter conditions. Pour supprimer des objets, sélectionnez-les, puis cliquez sur l'icône . Si le mappage des noms d'objets est utilisé, les autres objets dépendant des objets mappés peuvent ne pas être migrés.

Cliquez sur Next: Advanced Settings pour configurer les éléments suivants :

Parameter

Description

Dedicated Cluster for Task Scheduling

Par défaut, DTS planifie les tâches sur un cluster partagé. Pour une stabilité accrue, achetez un cluster dédié. Consultez la rubrique What is a DTS dedicated cluster.

Retry Time for Failed Connections

La fenêtre de nouvelle tentative en cas d'échec de connexion après le démarrage de la tâche. Valeurs valides : 10 à 1 440 minutes. Valeur par défaut : 720 minutes. Définissez une valeur supérieure ou égale à 30 minutes. Si DTS se reconnecte dans ce délai, la tâche reprend. Sinon, la tâche échoue. Lorsque plusieurs tâches partagent la même base de données, c'est le délai de nouvelle tentative défini le plus récemment qui s'applique. DTS facture l'instance pendant la période de nouvelle tentative.

Retry Time for Other Issues

La fenêtre de nouvelle tentative en cas d'échec des opérations DDL ou DML. Valeurs valides : 1 à 1 440 minutes. Valeur par défaut : 10 minutes. Définissez une valeur supérieure à 10 minutes. Cette valeur doit être inférieure au paramètre Retry Time for Failed Connections.

Enable Throttling for Full Data Migration

Limiter l'utilisation des ressources DTS lors de la migration complète des données. Configurez 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). Disponible uniquement lorsque l'option Full Data Migration est sélectionnée.

Only one data type for primary key _id in a table of the data to be synchronized

Indique si la clé primaire _id possède un type de données unique dans chaque collection. Yes : DTS ignore l'analyse des types de données de la clé primaire et migre un seul type par collection. No : DTS analyse et migre tous les types de données de la clé primaire. Activez cette option en fonction de vos données. Une configuration incorrecte peut entraîner une perte de données. Disponible uniquement lorsque l'option Full Data Migration est sélectionnée.

Enable Throttling for Incremental Data Migration

Limiter l'utilisation des ressources DTS lors de la migration incrémentielle des données. Configurez les paramètres RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s). Disponible uniquement lorsque l'option Incremental Data Migration est sélectionnée.

Environment Tag

Un tag pour identifier l'instance DTS. Facultatif.

Configure ETL

Active la fonctionnalité ETL (Extract, Transform, Load). Sélectionnez Yes pour saisir les instructions de traitement des données dans l'éditeur de code. Consultez la rubrique Configure ETL in a data migration or data synchronization task. Sélectionnez No pour ignorer l'ETL.

Monitoring and Alerting

Configure les alertes pour la tâche. Sélectionnez Yes pour définir un seuil d'alerte et des contacts de notification. Consultez la rubrique Configure monitoring and alerting when you create a DTS task.

Cliquez sur Next Step: Data Verification pour configurer la vérification des données. Consultez la rubrique Configure a data verification task.

Étape 6 : Exécuter la pré-vérification

Cliquez sur Next: Save Task Settings and Precheck.

Pour afficher un aperçu des paramètres d'API pour cette configuration de tâche, survolez Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters .

DTS exécute une pré-vérification avant le début de la migration. La tâche ne peut démarrer qu'une fois la pré-vérification réussie.

Si un élément de pré-vérification échoue, cliquez sur View Details à côté de celui-ci, résolvez le problème, puis relancez la pré-vérification.
Si un élément de pré-vérification déclenche une alerte :
- Si l'alerte ne peut pas être ignorée, cliquez sur View Details, résolvez le problème, puis relancez la pré-vérification.
- Si l'alerte peut être ignorée, cliquez sur Confirm Alert Details, puis sur Ignore dans la boîte de dialogue, et enfin sur OK. Cliquez sur Precheck Again pour continuer. Ignorer une alerte peut entraîner une incohérence des données.

Étape 7 : Acheter une instance

Attendez que le Success Rate atteigne 100 %, puis cliquez sur Next: Purchase Instance.

Sur la page Purchase Instance, configurez les éléments suivants :

Section	Parameter	Description
New Instance Class	Resource Group	Groupe de ressources pour l'instance de migration. Par défaut : default resource group. Consultez What is Resource Management?
New Instance Class	Instance Class	La classe d'instance détermine la vitesse de migration. Sélectionnez-la en fonction de vos besoins. Consultez Instance classes of data migration instances.

Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms en cochant la case correspondante.
Cliquez sur Buy and Start, puis sur OK dans la boîte de dialogue de confirmation.

La tâche apparaît sur la page Data Migration.

Migration complète des données uniquement : la tâche s'arrête automatiquement. Le statut indique Completed.
Migration incrémentielle des données : la tâche s'exécute en continu et ne s'arrête jamais automatiquement. Le statut indique Running.

Étape 8 : Créer des tâches pour les shards restants (le cas échéant)

Si la méthode Access Method pour la source est Self-managed Database on ECS ou Database Gateway, répétez les étapes 1 à 7 pour chaque shard restant.

Étape 9 : Arrêter les tâches de migration

Full data migration

N'arrêtez pas manuellement une tâche de migration complète des données, car les données migrées pourraient être incomplètes. Attendez que la tâche s'arrête automatiquement.

Incremental data migration

La migration incrémentielle des données ne s'arrête pas automatiquement. Arrêtez-la manuellement au moment approprié, par exemple pendant les heures creuses ou avant de basculer les charges de travail vers l'instance de destination.

Attendez que Incremental Data Migration apparaisse dans la barre de progression Running et que Undelayed s'affiche dans Operation Info. Ensuite, cessez d'écrire des données dans la base de données source pendant quelques minutes.
Une fois que le statut de Incremental Data Migration revient à Undelayed, arrêtez manuellement les tâches de migration pour tous les shards.

Étape 10 : Basculer les charges de travail vers l'instance de destination

Une fois la migration terminée et les données vérifiées, basculez vos charges de travail vers l'instance ApsaraDB for MongoDB de destination.