Tous les produits
Search

Ce produit

    Data Transmission Service:Migration de réplica sets vers des réplica sets ou des clusters fragmentés

    Centre de documentation

    Data Transmission Service:Migration de réplica sets vers des réplica sets ou des clusters fragmentés

    Dernière mise à jour :Aug 10, 2026

    Cette rubrique explique comment utiliser DTS pour migrer les données d'une instance ApsaraDB for MongoDB en réplica set vers une instance ApsaraDB for MongoDB en réplica set ou en cluster fragmenté.

    Bases de données source et destination prises en charge

    |
    **Base de données source (réplica set)**
    |
    **Base de données destination (réplica set ou cluster fragmenté)**
    | | --- | --- | |
    ApsaraDB for MongoDB
    |
    ApsaraDB for MongoDB
    | |
    Base de données autogérée sur une instance ECS
    |
    Base de données autogérée sur une instance ECS
    | |
    Base de données autogérée connectée via Express Connect, VPN Gateway ou Smart Access Gateway
    |
    Base de données autogérée connectée via Express Connect, VPN Gateway ou Smart Access Gateway
    | |
    Base de données autogérée disposant d'une adresse IP publique
    |
    Base de données autogérée disposant d'une adresse IP publique
    |

    Cette rubrique détaille le processus de configuration en prenant pour exemple une instance ApsaraDB for MongoDB (réplica set) et une instance ApsaraDB for MongoDB (réplica set ou cluster fragmenté). La procédure est similaire pour les autres sources de données.





















    Prérequis

    • Une instance source ApsaraDB for MongoDB en réplica set et une instance destination ApsaraDB for MongoDB (réplica set ou cluster fragmenté) ont été créées. Pour plus d'informations, consultez les rubriques Créer une instance en réplica set et Créer une instance en cluster fragmenté.

      Remarque

      Pour connaître les versions prises en charge, consultez la rubrique Présentation des solutions de migration.

    • L'espace de stockage de l'instance destination ApsaraDB for MongoDB doit être supérieur de 10 % à l'espace utilisé par l'instance source ApsaraDB for MongoDB.

    • Si l'instance destination ApsaraDB for MongoDB est un cluster fragmenté, créez les bases de données et collections nécessitant un fragmentation, configurez le sharding des données, activez l'équilibreur de charge (balancer) et effectuez un pré-sharding dans l'instance destination ApsaraDB for MongoDB selon vos besoins. Pour plus d'informations, consultez les rubriques Configurer le sharding 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 sharding des données empêche la migration de toutes les données vers un seul shard, garantissant ainsi des performances optimales pour le cluster. L'activation de l'équilibreur de charge et le pré-sharding évitent le déséquilibre des données.

    Notes d'utilisation

    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. À défaut, 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 risquent d'être créées dans la base de données destination.

    • Les noms de champs dans les données ne doivent pas contenir le caractère « . » (point), sous peine de provoquer des incohérences de données.

    • Si vous migrez des données au niveau des collections et que vous devez modifier les collections, par exemple en mappant les noms de collection, une seule tâche de migration peut traiter au maximum 1 000 collections. Si vous dépassez cette limite, la tâche signalera une erreur lors de la soumission. Dans ce cas, vous devez répartir 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.

    • Si la base de données source est Azure Cosmos DB for MongoDB ou un cluster élastique Amazon DocumentDB, seule la migration complète des données est prise en charge.

    • Pour effectuer une migration incrémentielle des données :

      La base de données source doit avoir l'oplog activé avec une rétention d'au moins sept jours. Alternativement, les change streams doivent être activés et DTS doit pouvoir s'abonner aux modifications de données de la source au cours des sept derniers jours via les change streams. Si ces exigences ne sont pas satisfaites, la tâche de migration peut échouer car elle ne parvient pas à obtenir les modifications de données depuis la source. Dans les cas extrêmes, cela peut entraîner une incohérence ou une perte de données. Les problèmes découlant de cette situation ne sont pas couverts par le contrat de niveau de service (SLA) de DTS.

      Important

      • Nous vous recommandons d'utiliser l'oplog pour obtenir les modifications de données depuis la base de données source.

      • Seules les versions MongoDB 4.0 et ultérieures prennent en charge l'obtention des modifications de données via les change streams.

      • Si la base de données source est un cluster Amazon DocumentDB (non élastique), vous devez activer manuellement les change streams. Lors de la configuration de la tâche, définissez la Migration Method sur ChangeStream et l'Architecture sur Sharded Cluster.

    • 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 aucune modification 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 destination.

      • Si vous n'effectuez qu'une migration complète des données, n'écrivez pas de nouvelles données dans l'instance source. Sinon, les bases de données source et destination deviendront incohérentes. Pour maintenir la cohérence des données en temps réel, sélectionnez Migration du schéma, Migration complète des données et Migration incrémentielle des données.

    • Si une collection à migrer contient un index TTL (Time-to-Live), des incohérences de données peuvent survenir ou la latence de l'instance peut augmenter.

    Autres limitations

    • Si l'instance destination possède une architecture en cluster fragmenté :

      • Vous devez supprimer les documents orphelins, car ils peuvent affecter les performances de migration. Si des documents présentant des conflits d'_id sont rencontrés pendant la migration, des incohérences de données ou un échec de la tâche peuvent survenir.

      • Avant de démarrer la tâche, vous devez ajouter une clé de sharding aux données source pour chaque collection fragmentée dans la destination. Si vous ne pouvez pas ajouter de clé de sharding aux données source, consultez la rubrique Migrer des données d'une instance MongoDB sans clé de sharding vers une instance de cluster fragmenté MongoDB.

      • Une fois la tâche démarrée, la commande INSERT doit inclure la clé de sharding. La commande UPDATE ne peut pas modifier la clé de sharding.

    • Si l'instance destination possède une architecture en réplica set :

      • 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 le Domain Name or IP et le 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 la rubrique Créer une instance source ou destination pour une base de données MongoDB haute disponibilité.

      • Lorsque la Access Method est Self-managed Database on ECS, vous devez définir le Port Number sur le port du nœud principal.

    • DTS ne prend pas en charge la connexion à une base de données MongoDB via un enregistrement SRV.

    • Maintenez la cohérence des versions MongoDB entre les bases de données source et 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 provoquer des problèmes de compatibilité.

    • DTS ne prend pas en charge la migration des données des bases de données admin, config ou local.

    • Si la collection 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 concurrente (seule l'écriture monothread est prise en charge) lors de la migration incrémentielle des données. Cela peut augmenter la latence de la tâche.

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

    • Lorsque DTS écrit des données dans une collection destination, si un conflit de clé primaire ou de clé unique se produit, DTS ignore l'instruction d'écriture conflictuelle et conserve les données existantes dans la collection destination.

    • Si la base de données source est une version MongoDB antérieure à la 3.6 et la base de données 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. Cela 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 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 destination. Par conséquent, les collections 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 ayant échoué dans un délai de sept jours. Avant la bascule du service vers l'instance cible, vous devez terminer ou libérer la tâche, ou utiliser la commande revoke pour révoquer les autorisations 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 automatiquement reprise.

    • Étant donné que DTS écrit les données de manière concurrente, la base de données 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 compte dans MongoDB destination.

    • Assurez-vous que la base de données MongoDB 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 entrent en conflit de la base de données destination avant la migration, à condition que cela n'affecte pas votre activité.

    • En cas d'échec d'une tâche, l'équipe d'assistance 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 la rubrique Modifier les paramètres de l'instance.

    • Si la base de données 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 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, permettant des suppressions explicites et des augmentations de taille de document 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 particuliers

    Si la base de données source est une base de données MongoDB autogérée :

    • Un basculement primaire/secondaire sur la base de données source pendant la migration entraîne l'échec de la tâche.

    • DTS calcule la latence en comparant l'horodatage du dernier enregistrement migré vers la destination avec l'horodatage actuel. Si la base de données source n'a pas été mise à jour depuis longtemps, la latence signalée peut être inexacte. Si la tâche affiche une latence excessive, effectuez une petite mise à jour sur la base de données source pour actualiser la valeur de latence.

    Remarque

    Si vous migrez une base de données entière, vous pouvez également créer une table de heartbeat mise à jour à intervalles réguliers, par exemple toutes les secondes.

    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 destination est défini sur Public IP Address, des frais de trafic Internet vous sont facturés. Pour plus d'informations, consultez la rubrique Présentation de la facturation.

    Migration incrémentielle des données

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

    Types de migration

    Type

    Description

    Migration du schéma

    DTS migre les schémas des objets sélectionnés depuis l'instance ApsaraDB for MongoDB source vers l'instance ApsaraDB for MongoDB de destination.

    Remarque

    DTS prend en charge la migration du schéma pour les bases de données, les collections et les index.

    Migration complète des données

    DTS migre toutes les données existantes des objets sélectionnés depuis l'instance ApsaraDB for MongoDB source vers l'instance ApsaraDB for MongoDB de destination.

    Remarque

    DTS prend en charge la migration complète des données pour les bases de données et les collections.

    Migration incrémentielle des données

    Une fois la migration complète des données terminée, DTS réplique les modifications de données en cours depuis l'instance ApsaraDB for MongoDB source vers l'instance ApsaraDB for MongoDB de destination.

    Utiliser oplog

    DTS ne réplique pas les données provenant des bases de données créées après le démarrage de la tâche. Les mises à jour incrémentielles suivantes sont prises en charge :

    • CREATE COLLECTION et CREATE INDEX

    • DROP DATABASE, DROP COLLECTION et DROP INDEX

    • RENAME COLLECTION

      Remarque

      Les opérations RENAME COLLECTION qui incluent l'option dropTarget définie sur true ne sont pas prises en charge.

    • Insertion, mise à jour et suppression de documents dans une collection.

      Remarque

      Pour les mises à jour incrémentielles de documents, seules les modifications effectuées à l'aide de la commande $set sont répliquées.

    Utiliser change streams

    Les mises à jour incrémentielles suivantes sont prises en charge :

    • DROP DATABASE et DROP COLLECTION

    • RENAME COLLECTION

      Remarque

      Les opérations RENAME COLLECTION qui incluent l'option dropTarget définie sur true ne sont pas prises en charge.

    • Insertion, mise à jour et suppression de documents dans une collection.

      Remarque

      Pour les mises à jour incrémentielles de documents, seules les modifications effectuées à l'aide de la commande $set sont répliquées.

    Autorisations des comptes de base de données

    Base de données

    Migration du schéma

    Migration complète des données

    Migration incrémentielle des données

    Instance ApsaraDB for MongoDB source

    Autorisation de lecture sur la base de données à migrer et sur la base de données config.

    Autorisation de lecture sur la base de données à migrer, sur la base de données admin et sur la base de données local.

    Instance ApsaraDB for MongoDB de destination

    L'autorisation dbAdminAnyDatabase, l'autorisation readWrite sur la base de données de destination et l'autorisation de lecture sur la base de données local.

    Pour créer et autoriser des comptes de base de données pour les instances ApsaraDB for MongoDB source et de destination, consultez la rubrique Gérer les utilisateurs de base de données MongoDB avec DMS.

    Procédure

    1. Accédez à la page de liste des tâches de migration pour la région de destination en utilisant l'une des méthodes suivantes.

      Depuis la console DTS

      1. Connectez-vous à la console Data Transmission Service (DTS).

      2. Dans le volet de navigation de gauche, cliquez sur Data Migration.

      3. Dans l’angle 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 les rubriques 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.

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

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

      Avertissement

      Après avoir sélectionné les instances source et de destination, nous vous recommandons de lire attentivement les limites affichées en haut de la page. À défaut, la tâche pourrait échouer ou entraîner une incohérence des données.

      Catégorie

      Paramètre

      Description

      S.O.

      Task Name

      DTS génère automatiquement un nom de tâche. Nous vous recommandons de spécifier un nom descriptif pour faciliter l'identification. 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 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 auprès du 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 MongoDB.

      Access Method

      Sélectionnez Cloud Instance.

      Instance Region

      Sélectionnez la région où se trouve l'instance ApsaraDB for MongoDB source.

      Replicate Data Across Alibaba Cloud Accounts

      Dans cet exemple, une instance de base de données appartenant au compte Alibaba Cloud actuel est utilisée. Sélectionnez No.

      Architecture

      Sélectionnez Replica set architecture.

      • replica set architecture : modèle de déploiement utilisant plusieurs nœuds pour garantir la haute disponibilité et permettre la séparation lecture/écriture. Pour plus d'informations, consultez la rubrique replica set architecture.

      • sharded cluster architecture : modèle de déploiement composé des composants mongos, shard et ConfigServer. Vous pouvez personnaliser le nombre et les configurations des nœuds mongos et shard. Pour plus d'informations, consultez la rubrique sharded cluster architecture.

      Migration Method

      Sélectionnez une méthode de migration incrémentielle des données en fonction de vos besoins.

      • Oplog (recommandé) :

        Cette option est disponible si Oplog est activé pour la base de données source.

        Remarque

        Oplog est activé par défaut pour les bases de données MongoDB autogérées et les instances ApsaraDB for MongoDB. Cette méthode offre une latence plus faible pour la migration incrémentielle des données grâce à une extraction plus rapide des journaux. Par conséquent, nous vous recommandons de sélectionner Oplog.

      • ChangeStream : cette option est disponible si Change Streams sont activés pour la base de données source.

        Remarque

        • Si la base de données source est une instance Amazon DocumentDB (cluster non élastique), vous ne pouvez sélectionner que ChangeStream.

        • Si vous définissez Architecture sur Sharded Cluster pour la base de données source, vous n'avez pas besoin de saisir un Shard account ni un Shard password.

      Instance ID

      Sélectionnez l'ID d'instance de l'instance ApsaraDB for MongoDB source.

      Authentication Database Name

      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 connaître les exigences en matière d'autorisations, consultez la section Autorisations du compte 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 disponibles pour 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 SSL-encrypted.

      • Si la source est une base de données MongoDB autogérée (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 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 auprès du 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 MongoDB.

      Access Method

      Sélectionnez Cloud Instance.

      Instance Region

      Sélectionnez la région où se trouve l'instance ApsaraDB for MongoDB de destination.

      Replicate Data Across Alibaba Cloud Accounts

      Dans cet exemple, une instance de base de données appartenant au compte Alibaba Cloud actuel est utilisée. Sélectionnez No.

      Architecture

      Sélectionnez une architecture en fonction de vos besoins métier. Valeurs possibles :

      • replica set architecture : modèle de déploiement utilisant plusieurs nœuds pour garantir la haute disponibilité et permettre la séparation lecture/écriture. Pour plus d'informations, consultez la rubrique replica set architecture.

      • sharded cluster architecture : modèle de déploiement composé des composants mongos, shard et ConfigServer. Vous pouvez personnaliser le nombre et les configurations des nœuds mongos et shard. Pour plus d'informations, consultez la rubrique sharded cluster architecture.

      Instance ID

      Sélectionnez l'ID d'instance de l'instance ApsaraDB for MongoDB de destination.

      Authentication Database Name

      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 connaître les exigences en matière d'autorisations, consultez la section Autorisations du compte 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 disponibles pour 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 dont l'Architecture est Sharded Cluster ne prennent pas en charge SSL-encrypted.

      • Si la destination est une base de données MongoDB autogérée (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.

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

      Remarque

      • Assurez-vous que les plages CIDR des serveurs DTS ont été ajoutées aux paramètres de sécurité des bases de données source et de destination pour autoriser l'accès depuis les serveurs DTS. Cette opération peut être effectuée automatiquement ou manuellement. Pour plus d'informations, consultez la rubrique Ajouter les plages CIDR des serveurs DTS à une liste d'autorisation.

      • Si la base de données source ou de destination est une base de données autogérée (où 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.

    5. Configurez les objets de la tâche.

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

        Parameter

        Description

        Migration Types

        • Si vous devez uniquement effectuer une migration complète, sélectionnez à la fois Schema Migration et Full Data Migration.

        • Pour réaliser une migration sans interruption de service, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration.

        Remarque

        • Si vous ne sélectionnez pas Schema Migration, vous devez vous assurer qu'une base de données et des tables destinées à recevoir les données existent dans la base de données de destination. Vous pouvez également utiliser la fonctionnalité de mappage des noms d'objets dans la zone Selected Objects selon vos besoins.

        • Si vous ne sélectionnez pas Incremental Data Migration, n'écrivez aucune nouvelle donnée dans l'instance source pendant la migration afin de garantir la cohérence des données.

        Pour plus d'informations, consultez la section Types de migration.

        Processing Mode of Conflicting Tables

        • Precheck and Report Errors : vérifie l'existence de collections portant le même nom dans la base de données de destination. Si aucune collection homonyme n'existe, la prévérification est validée. En cas de collision de noms, une erreur est signalée lors de la prévérification et la tâche de migration ne démarre pas.

          Remarque

          Si une collection de la base de données de destination porte le même nom mais ne peut pas être facilement supprimée ou renommée, vous pouvez modifier le nom de cette collection dans la base de données de destination. Pour en savoir plus, consultez la rubrique Mappage des noms d'objets.

        • Ignore Errors and Proceed : ignore la vérification des collections portant le même nom.

          Avertissement

          Le choix de l'option Ignore Errors and Proceed peut entraîner des incohérences de données et présenter des risques pour votre activité. Par exemple :

          • Si un enregistrement de la base de données de destination possède la même valeur de clé primaire qu'un enregistrement de la base de données source, l'enregistrement de destination est conservé. L'enregistrement provenant de la source n'est pas migré vers la destination.

          • L'initialisation des données peut échouer, seule une partie des données peut être migrée ou la migration peut échouer complètement.

        Capitalization of Object Names in Destination Instance

        Vous pouvez configurer la règle de casse appliquée aux noms des bases de données et des collections migrés dans l'instance de destination. Par défaut, l'option DTS default policy est sélectionnée. Vous avez également la possibilité d'aligner la configuration sur les politiques par défaut de la base de données source ou de destination. Pour plus de détails, reportez-vous à la section Politique de casse des noms d'objets pour la destination.

        Source Objects

        Dans la zone Source Objects, cliquez sur un objet à migrer, puis cliquez sur l'icône 向右小箭头 pour le déplacer vers la zone Selected Objects.

        Remarque

        Vous pouvez sélectionner des objets au niveau DATABASE ou COLLECTION pour la migration.

        Selected Objects

        • Pour définir le nom d'un objet migré dans l'instance de destination, ou pour spécifier l'objet recevant les données dans cette instance, faites un clic droit sur l'objet de migration dans la zone Selected Objects afin d'effectuer les modifications nécessaires. Consultez la rubrique Mappage des noms d'objets pour plus d'informations.

        • Pour supprimer un objet de migration sélectionné, cliquez dessus dans la zone Selected Objects, puis cliquez sur image pour le renvoyer dans la zone Source Objects.

        Remarque

        • Pour sélectionner les opérations de migration incrémentielle au niveau de la base de données ou de la collection, faites un clic droit sur l'objet de migration dans la zone Selected Objects et effectuez votre choix dans la boîte de dialogue qui s'affiche.

        • Pour définir des conditions de filtrage des données (pris en charge lors de la migration complète des données, mais pas lors de la migration incrémentielle), faites un clic droit sur la collection dans la zone Selected Objects et configurez les paramètres dans la boîte de dialogue correspondante. Suivez les instructions de la rubrique Définir des conditions de filtrage.

        • Si vous utilisez la fonctionnalité de mappage des noms d'objets pour désigner une base de données ou une collection comme réceptacle des données, la migration d'autres objets dépendants de cet objet risque d'échouer.

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

        Parameter

        Description

        Dedicated Cluster for Task Scheduling

        Par défaut, DTS planifie les tâches sur un cluster partagé. Aucune sélection n'est requise. Si vous souhaitez une stabilité accrue pour vos tâches, 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 tente immédiatement de rétablir la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser cette durée entre 10 et 1 440 minutes. Il est recommandé de définir une durée supérieure à 30 minutes. Si DTS parvient à se reconnecter aux bases de données source et de destination dans le délai imparti, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue.

        Remarque

        • Pour plusieurs instances DTS partageant la même source ou la même destination, le temps de nouvelle tentative réseau est déterminé par le paramétrage de la dernière tâche créée.

        • Étant donné que la tâche est facturée pendant la période de nouvelle tentative de connexion, nous vous conseillons 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

        Après le démarrage de la tâche de migration, si un problème autre qu'un défaut de connectivité survient dans la base de données source ou de destination (par exemple, une exception lors de l'exécution d'une instruction DDL ou DML), DTS signale une erreur et tente immédiatement de relancer l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser cette durée entre 1 et 1 440 minutes. Il est recommandé de définir une durée supérieure à 10 minutes. Si les opérations concernées aboutissent dans le délai de nouvelle tentative spécifié, la tâche de migration reprend automatiquement. Sinon, la tâche échoue.

        Important

        La valeur du paramètre Retry Time for Other Issues doit être inférieure à celle du paramètre Retry Time for Failed Connections.

        Enable Throttling for Full Data Migration

        Lors de 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 leur charge. Si nécessaire, vous pouvez activer la limitation du 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 de destination.

        Remarque

        • Cet élément de configuration est disponible uniquement si vous sélectionnez l'option Full Data Migration pour le paramètre 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

        Indique si le type de données de la clé primaire _id est unique au sein d'une seule collection à migrer.

        Important

        • Sélectionnez une option en fonction de vos besoins. À défaut, des pertes de données pourraient survenir.

        • Ce paramètre est disponible uniquement si vous sélectionnez l'option Full Data Migration pour le paramètre Migration Types.

        • Yes : le type de données est unique. Lors de la migration complète des données, DTS n'analyse pas les types de données des clés primaires dans la base de données source. Au sein d'une seule collection, DTS migre uniquement les données correspondant à un seul type de données de clé primaire.

        • No : le type de données n'est pas unique. Lors de la migration complète des données, DTS analyse les types de données des clés primaires dans la base de données source et migre toutes les données.

        Enable Throttling for Incremental Data Migration

        Si nécessaire, vous pouvez également choisir de limiter la vitesse de la tâche de migration incrémentielle. Définissez les paramètres RPS of Incremental Data Migration et Data migration speed for incremental 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 l'option Incremental Data Migration pour le paramètre Migration Types.

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

        Environment Tag

        Vous pouvez sélectionner un tag d'environnement pour identifier l'instance. Dans cet exemple, ce paramètre est facultatif.

        Configure ETL

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

        Monitoring and Alerting

        Choisissez ou non de configurer des alertes et de recevoir des notifications d'alerte en fonction de vos besoins métier.

        • No : ne configure aucune alerte.

        • Yes : configurez les alertes en définissant un seuil d'alerte et des notifications d'alerte. En cas d'échec de la migration ou si la latence dépasse le seuil défini, le système envoie une notification d'alerte.

      3. Cliquez sur Next: Data Validation pour configurer une tâche de validation des données.

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

    6. Enregistrez la tâche et exécutez une prévérification.

      • Pour afficher les paramètres de configuration de cette instance lors de l'appel de l'opération API, placez le pointeur sur le bouton Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters dans la bulle qui s'affiche.

      • Si vous n'avez pas besoin de consulter les paramètres API ou si vous avez terminé leur consultation, 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émarre qu'après la réussite de cette étape.

      • Si la prévérification échoue, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème selon les instructions, puis relancez la prévérification.

      • Si un avertissement est émis lors de la prévérification :

        • Pour les éléments de vérification qui ne peuvent pas être ignorés, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème selon les instructions, puis relancez la prévérification.

        • Pour les éléments de vérification pouvant être ignorés, vous pouvez cliquer sur Confirm Alert Details, Ignore, OK et Precheck Again afin d'ignorer l'avertissement et de relancer la prévérification. Notez que l'ignorance d'un avertissement peut entraîner des problèmes tels que des incohérences de données et présenter des risques pour votre activité.

    7. Achetez l'instance.

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

      2. Sur la page Purchase, sélectionnez la spécification de lien pour l'instance de migration des données. Pour plus d'informations, consultez le tableau ci-dessous.

        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 la gestion des ressources ?

        Instance Class

        DTS propose des spécifications de migration offrant différents niveaux de performance. La spécification du lien influence la vitesse de migration. Vous pouvez choisir une spécification adaptée à votre scénario métier. Pour plus d'informations, consultez Spécifications des liens de migration des données.

      3. Une fois la configuration terminée, lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.

      4. 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 sur la page de liste Data Migration Tasks.

        Remarque

        • Si la tâche de migration n'inclut pas de migration incrémentielle, elle s'arrête automatiquement une fois la migration complète terminée. Une fois la tâche arrêtée, son Status passe à Completed.

        • Si la tâche de migration inclut une migration incrémentielle, elle ne s'arrête pas automatiquement. La tâche de migration incrémentielle continue de s'exécuter. Pendant l'exécution de la tâche de migration incrémentielle, le Status de la tâche est Running.

    FAQ

    • Pourquoi observez-vous une latence des tâches et une incohérence des données, même en l’absence d’écritures actives depuis les applications ?

      • Cause : Ce problème résulte d’un conflit entre le mécanisme de suppression automatique d’un TTL index sur une collection MongoDB et le mécanisme de data synchronization de DTS. Ce conflit engendre une task latency et une data inconsistency.

        • Les suppressions redondantes réduisent l’efficacité : Lorsque l’index TTL source supprime les données expirées, il inscrit une opération DELETE dans l’Oplog. DTS rejoue cette suppression sur la destination. Si l’index TTL de la destination a déjà supprimé ces mêmes données, MongoDB renvoie un nombre de lignes affectées inattendu, ce qui déclenche la gestion des exceptions et ralentit la migration.

        • Incohérence des données due à la suppression asynchrone par TTL : Les index TTL ne suppriment pas les données en temps réel. Il est possible que des données expirées soient encore présentes sur la source alors qu’elles ont déjà été supprimées sur la destination, provoquant ainsi une incohérence.

          Exemple :

          L’Oplog ou le ChangeStream de MongoDB n’enregistre que les champs modifiés lors d’une opération UPDATE, et non le document complet. Si une opération UPDATE ne trouve pas les données cibles sur la destination, DTS ignore l’opération.

          |
          **Moment**
          |
          **Instance source**
          |
          **Instance de destination**
          | | --- | --- | --- | |
          1
          |
          Le service insère des données
          |

          | |
          2
          |

          |
          DTS synchronise l’opération INSERT
          | |
          3
          |
          Les données ont expiré mais n’ont pas encore été supprimées par l’index TTL
          |

          | |
          4
          |
          Le service met à jour les données (par exemple, il modifie le champ de l’index TTL pour changer l’heure d’expiration)
          |

          | |
          5
          |

          |
          L’index TTL supprime les données
          | |
          6
          |

          |
          DTS synchronise l’opération UPDATE, mais les données sont introuvables. L’opération est ignorée.
          |

          Par conséquent, ce document est absent de l’instance MongoDB de destination.











































      • Solution : Pour résoudre ce problème, modifiez temporairement la durée d’expiration de l’TTL index sur la target pendant la synchronization/migration task. Cette approche garantit à la fois l’efficacité de la synchronisation et la data consistency. Pour plus de détails, consultez la rubrique Bonnes pratiques pour la synchronisation ou la migration de collections avec des index TTL depuis une source MongoDB.