Data Transmission Service:Migrer des données d'une base de données MongoDB gérée par vos soins (architecture de cluster fragmenté) vers une instance ApsaraDB for MongoDB (architecture de jeu de réplicas ou de cluster fragmenté)

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 comporter des contraintes PRIMARY KEY 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 de destination lors de 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 de 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 s'affichent 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 gérée par vos soins source ne peut pas comporter plus de 10 nœuds mongos.

• Ne migrez pas de collections dotées d'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 dans l'instance de cluster fragmenté de destination. Les documents orphelins peuvent entraîner 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 fragmenté ?

Pendant la migration, n'exécutez pas les commandes suivantes sur la base de données source, car 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 entraînent 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 n'effectuez que 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 le balancier 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 fragmentation à 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 des clés de fragmentation et les opérations UPDATE ne doivent pas modifier les clés de fragmentation.

• Désactivez le balancier 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 entraîne des incohérences de données. Consultez Gérer le balancier ApsaraDB for MongoDB

• Assurez-vous que la base de données de destination ne contient pas déjà de documents avec 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 survient lorsque DTS écrit dans la destination, DTS ignore l'écriture conflictuelle et conserve les données existantes.

• Ne mettez pas à l'échelle une instance ApsaraDB for MongoDB de cluster fragmenté pendant l'exécution d'une tâche de migration. La mise à l'échelle entraîne 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 supérieur de 5 à 10 % à celui de 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 ainsi 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 ayant échoué 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 ayant échoué, ou révoquez les autorisations d'écriture 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, le support 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 la connexion s'effectue via Express Connect, VPN Gateway, Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN) : définissez Domain Name or IP et Port Number