Planification de la migration de MongoDB vers Cosmos DB
Après avoir examiné les avantages de Cosmos DB, votre directeur informatique vous a donné la suite pour exécuter une preuve de concept. La première phase du projet consiste à planifier la migration des données. Cela inclut la configuration d’un Cosmos DB vide pour héberger les données migrées.
Dans cette unité, vous allez suivre les étapes de création d’une base de données Cosmos DB et sélectionner une méthode de migration hors connexion ou en ligne.
Vérifier la compatibilité de mongoDB
La première tâche avant la migration consiste à vérifier que vous effectuez une migration à partir d’une version prise en charge de MongoDB. Vous pouvez vérifier la prise en charge de la dernière version sur le site suivant :
l’API Azure Cosmos DB pour MongoDB : fonctionnalités et syntaxe prises en charge
Pour commencer à utiliser cosmos DB dans Azure, vous créez un compte Cosmos DB avec l’API MongoDB. Ensuite, vous créez une base de données dans le compte. Vous pouvez séparer vos charges de travail de base de données dans différentes bases de données. L’avantage de cette approche est la granularité à laquelle vous pouvez définir le débit.
L’accès à vos données est contrôlé en utilisant des réseaux virtuels Azure (VNet). Vous allez configurer votre groupe de sécurité réseau de réseau virtuel pour ouvrir les ports 53, 443, 445, 9354 et 10000-20000. Évidemment, vous devez également configurer vos pare-feu locaux pour autoriser l’accès via ces ports à votre serveur MongoDB local.
En règle générale, une migration implique une grande quantité de transfert de données et vous pouvez augmenter temporairement le débit pendant la migration. Si vous spécifiez un débit au niveau de la base de données, vous devez considérer que chaque collection nécessite au moins 100 RU/s. Par conséquent, la ru/s minimale pour la base de données est le nombre de collections multipliées par 100. Le débit au niveau de la base de données semble souvent plus approprié que le débit au niveau de la collecte pour les scénarios de migration, mais vous devez considérer que ce paramètre ne peut pas être modifié après la création et, par conséquent, vous devez choisir le paramètre le plus approprié pour l’utilisation attendue de la base de données après la migration.
Migration hors connexion ou en ligne
Dans une migration hors connexion, vous arrêtez les connexions à la base de données, effectuez la migration, puis établissez des connexions à la nouvelle base de données migrée. Il est importé pour empêcher les connexions pendant la migration, car ces transactions seront perdues.
Une migration en ligne applique toutes les transactions qui se produisent lors de la migration vers la nouvelle base de données migrée. Aucune transaction n’est perdue.
Une migration hors connexion est plus rapide, mais une migration en ligne a moins de temps d’arrêt. Le temps d’arrêt commence lorsque la migration démarre en mode hors connexion, mais le temps d’arrêt commence uniquement à la fin de la migration lorsque le basculement vers la nouvelle base de données se produit en ligne. Vous devez exécuter un test de migration hors connexion sur une copie du système en direct pour déterminer si le temps d’arrêt est acceptable. Il peut être possible d’exécuter la migration à la fois où l’activité est généralement faible. Si le temps d’arrêt de la migration hors connexion n’est pas acceptable, choisissez la migration en ligne.
Pour plus d’informations sur les migrations en ligne, consultez Migrer MongoDB vers l’API Mongo Azure Cosmos DB en ligne
Pour plus d’informations sur les migrations hors connexion, consultez Migrer MongoDB vers l’API Mongo Azure Cosmos DB hors connexion