L'extension de migration Azure Cosmos DB for MongoDB vous permet de migrer vos charges de travail MongoDB vers Azure Cosmos DB. Cet article répond aux questions fréquentes sur l’extension de migration.
Comment faire pour exécuter mon évaluation en cas d’échec de l’étape « Exécuter la validation » ?
Reportez-vous à l’erreur affichée sur l’extension pour savoir pourquoi la validation échoue. En règle générale, le problème est lié à une incapacité à se connecter au point de terminaison MongoDB. Le problème peut également être dû au fait que l’utilisateur ne dispose pas de privilèges suffisants sur le serveur connecté pour exécuter l’évaluation.
Pour exécuter une évaluation, l’utilisateur connecté à MongoDb doit avoir les rôles readAnyDatabase et clusterMonitor attribués sur l’instance source.
Utilisez grantRolesToUser pour configurer les rôles appropriés pour l’utilisateur actuellement connecté.
Comment faire pour voir les noms des collections et des bases de données pour les évaluations dans la catégorie « Compatibilité des fonctionnalités » ?
L’évaluation utilise la commande serverStatus pour effectuer l’évaluation de la compatibilité des fonctionnalités. Étant donné que cette commande ne fournit pas les détails des noms de bases de données ou des collections, l’extension ne peut pas signaler le nom des ressources.
Pour obtenir des détails plus précis sur l’évaluation, réexécutez-la en fournissant le chemin d’accès du dossier contenant les journaux d’activité du profileur MongoDB dans le champ Chemin du dossier des journaux.
Comment faire pour récupérer les messages de journal ?
Vous pouvez localiser le fichier journal en suivant le chemin d’accès : /var/log/mongodb/mongodb.log. Si le fichier journal est introuvable, vérifiez l’emplacement dans le fichier de configuration MongoDB.
Pour plus d’informations, consultez Messages du journal d’activité MongoDB.
Une fois la migration démarrée, pourquoi vois-je une estimation au lieu du nombre exact de documents migrés?
Pour réduire l’utilisation des ressources sur la source pendant la migration, l’extension estime le nombre de documents de chaque collection à déplacer de la source vers la cible au lieu de récupérer le nombre exact.
Pourquoi certaines collections sont-elles manquantes ou désactivées à l’étape de mappage de collection ?
Azure Cosmos DB for MongoDB basé sur vCore ne prend pas en charge les séries chronologiques ni les collections en groupement. Par conséquent, ces types de collections sont manquants ou désactivés à l’étape de mappage de collection.
Pourquoi les vues sont-elles manquantes ou désactivées à l’étape de mappage de collection quand Azure Cosmos DB for MongoDB basé sur vCore prend en charge les vues ?
Azure Cosmos DB for MongoDB basé sur vCore prend en charge la création de vues. Toutefois, l’extension de migration ne prend pas en charge la migration des vues existantes.
Une fois la migration terminée, vous pouvez toujours recréer les vues.
Combien de stockage dois-je m’attendre à utiliser dans le compte cible après la migration ?
Azure Cosmos DB for MongoDB basé sur vCore ne compresse pas les données sur le disque. Une estimation approximative habituelle consiste à doubler la taille de stockage consommée par les collections sur l’instance MongoDB source pour estimer le stockage dans le compte Azure Cosmos DB for MongoDB basé sur vCore cible.
Quelles sont les collections et bases de données ignorées lors de la migration de MongoDB vers Azure Cosmos DB for MongoDB basé sur vCore ?
Les bases de données et collections suivantes sont considérées comme internes à MongoDB :
| Ressource | |
|---|---|
| Bases de données | admin, local, system config |
| Collections | Toute collection avec le préfixe system. |
Étant donné que les bases de données et collections internes ne sont pas requises dans Azure Cosmos DB for MongoDB basé sur vCore, l’extension n’active pas la migration de ces bases de données.
Est-il possible de migrer des bases de données et des collections dont les noms commencent par des nombres ?
Il s’agit d’un problème connu. La migration ne prend pas en charge les bases de données et les collections dont les noms commencent par des nombres.
Si je sélectionne plusieurs collections à migrer, leur migration est-elle effectuée en parallèle ?
Chaque tâche de migration dans Azure Database Migration Service fournit deux trains pour la migration. Chaque train effectue la migration d’une collection à tout moment. Par conséquent, la migration de deux collections s’effectue généralement en parallèle. Une fois la migration d’une collection terminée, la collection suivante est automatiquement récupérée. Si vous devez effectuer la migration de nombreuses collections, créez plusieurs tâches de migration. Chaque tâche doit avoir un nombre limité de collections pour aider à rendre les migrations plus efficaces.
Combien de bases de données et de collections puis-je faire migrer en une seule migration ?
Il n’existe aucune limite quant au nombre de bases de données et de collections qui peuvent être incluses dans une seule migration. Toutefois, les collections sélectionnées sont divisées en lots de 50 lors de la création des tâches de migration sur Azure Database Migration Service. Pour les grandes quantités de collections, plusieurs tâches de migration s’affichent dans la liste des migrations.
Comment planifier l’ordre et la quantité des collections à migrer ?
Lorsque vous sélectionnez plusieurs collections à migrer, l’ordre dans lequel la migration des collections est effectuée n’est pas configurable. Si vous souhaitez contrôler l’ordre de migration, effectuer la migration des collections en lots plus petits en fonction de l’ordre souhaité. Pour des performances optimales, évitez de combiner des collections plus volumineuses avec des collections plus petites dans un lot.
Comment configurer mes pare-feu Azure Cosmos DB for MongoDB basé sur vCore et MongoDB pour éviter les problèmes de connectivité ?
Ajoutez des exceptions de pare-feu au compte cible Azure Cosmos DB for MongoDB basé sur vCore pour accepter les connexions à partir de centres de données Azure globaux. Pour en savoir plus, consultez Configuration du pare-feu Azure Cosmos DB.
Comment configurer mes pare-feu de serveur source pour éviter les problèmes de connectivité ?
Configurez l’instance MongoDB source pour autoriser les connexions à partir des centres de données Azure globaux. Pour plus d’informations, consultez Plages d’adresses IP globales dans Azure.
Avertissement
L’extension ne prend pas en charge les instances MongoDB source ou cible avec point de terminaison privé activé. L’extension ne prend pas en charge le runtime d’intégration auto-hébergé d’Azure Database Migration Service.
Les tâches de migration s’exécutent-t-elles localement sur mon ordinateur ?
La base de données, les collections et les index sont créés directement à l’aide de commandes à partir du client Azure Data Studio local. Cette fonctionnalité nécessite une connectivité entre le client exécutant Azure Data Studio avec les environnements source et cible.
Les tâches de migration des données sont exécutées sur Azure Database Migration Service. Le service de migration est une instance de service Azure qui orchestre et effectue des activités de déplacement de données. Une fois les tâches de migration des données créées, vous n’êtes pas obligé d’être connecté aux environnements source et cible.
Combien de migrations puis-je exécuter simultanément ?
Il n’existe aucune limite quant au nombre de migrations que vous pouvez créer simultanément.
Puis-je renommer des bases de données et des collections pendant la migration ?
L’extension ne prend pas en charge le changement de nom des bases de données et des collections pendant la migration.
Puis-je effectuer la migration des collections via plusieurs itérations de migration ?
Il est possible de créer plusieurs tâches de migration comportant chacune un nombre limité de collections. Cette approche fait partie des meilleures pratiques pour optimiser la vitesse des migrations.
Que contient un rapport d’évaluation ?
La partie initiale du rapport contient les détails clés de l’exécution de l’évaluation, notamment un résumé de l’environnement MongoDB source. Les détails incluent la version de MongoDB source, le type de licence et le type d’instance. Cette partie contient également une liste des bases de données et collections évaluées, avec leurs résumés d’évaluation respectifs et leur préparation à la migration.
Les résultats sont regroupés en catégories Critique, Avertissement et Information. Ces catégories vous aident à classer les résultats par ordre de priorité en fonction de leur importance.
Les vérifications de l’évaluation comprennent :
| Description | |
|---|---|
| Options de collection | Rrésultats liés aux paramètres de collection non pris en charge. Il s’agit par exemple des séries chronologiques et des classements. |
| Caractéristiques | Résultats liés aux commandes de base de données, à la syntaxe de requête ou aux opérateurs non pris en charge, y compris les requêtes de pipeline d’agrégation. Dans la colonne de détails supplémentaires, vous pouvez voir la fréquence à laquelle la fonctionnalité en question était utilisée sur le point de terminaison source. |
| Limites et quotas | Résultats liés aux quotas et limites propres à Azure Cosmos DB for MongoDB basé sur vCore. |
| Index | Résultats liés aux propriétés ou types d’index MongoDB non pris en charge. |
| Clés de partition | Résultats liés aux configurations de clé de partition non prises en charge. |
Quel type de journaux l’extension crée-t-elle ?
L’extension stocke les erreurs, les avertissements et d’autres journaux de diagnostic dans le répertoire des journaux par défaut :
- Windows -
C:\Users\<username>\.dmamongo\logs\ - Linux –
~/.dmamongo/logs - macOS –
/Users/<username>/.dmamongo/logs
Notes
Un fichier journal distinct est créé pour chaque jour. Par défaut, l’extension stocke les sept derniers fichiers journaux.