Planification de la migration de MongoDB vers Cosmos DB
Après avoir passé en revue les avantages de Cosmos DB, votre directeur informatique vous donne le feu vert pour effectuer une preuve de concept. La première phase du projet consiste à planifier la migration des données. Cela suppose notamment de configurer une base de données Cosmos DB vide pour héberger les données migrées.
Dans cette unité, vous allez parcourir les différentes étapes de création d’une base de données Cosmos DB et sélectionner une méthode de migration en ligne ou hors connexion.
Vérifier la compatibilité de votre version de MongoDB
Avant de procéder à la migration, vous devez dans un premier temps vérifier que vous effectuez l’opération à 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 :
API Azure Cosmos DB pour MongoDB : fonctionnalités et syntaxe prises en charge
Pour commencer à utiliser Cosmos DB dans Azure, créez un compte Cosmos DB avec l’API MongoDB. Créez ensuite 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 qu’elle permet de définir la granularité du débit.
L’accès à vos données est contrôlé par l’utilisation de réseaux virtuels Azure (VNet). Vous allez configurer votre groupe de sécurité réseau VNET de façon à ouvrir les ports 53, 443, 445, 9354 et 10000-20000. Il va de soi que vous devrez aussi configurer vos pare-feu locaux en vue d’autoriser l’accès à votre serveur MongoDB local via ces ports.
En règle générale, une migration implique un important transfert de données. À ce titre, vous pouvez augmenter temporairement le débit pendant la migration. Si vous spécifiez le débit au niveau de la base de données, vous devez savoir que chaque collection nécessite au moins 100 RU/s. Par conséquent, le nombre minimal de RU/s nécessaires à la base de données correspond au nombre de collections multiplié par 100. Le débit au niveau de la base de données semble souvent plus adapté aux scénarios de migration que le débit au niveau de la collection, mais vous devez savoir que ce paramètre ne peut pas être modifié après la création. Par conséquent, vous devez choisir le paramètre le mieux adapté à l’utilisation attendue de la base de données après la migration.
Migrations hors connexion ou en ligne
Dans une migration hors connexion, vous mettez fin aux connexions à la base de données, effectuez la migration, puis établissez des connexions à la nouvelle base de données migrée. Il est important d’empêcher les connexions pendant la migration, car ces transactions seront perdues.
Dans une migration en ligne, toutes les transactions qui se produisent pendant la migration sont appliquées dans la nouvelle base de données migrée. Aucune transaction n’est perdue.
Si une migration hors connexion s’avère plus rapide, une migration en ligne implique moins de temps d’arrêt. Dans le cas d’une migration hors connexion, le temps d’arrêt intervient au début de l’opération. Dans le cas d’une migration en ligne, il intervient uniquement à la fin de l’opération quand le basculement vers la nouvelle base de données se produit. Vous avez tout intérêt à exécuter un test de migration hors connexion sur une copie du système actif pour déterminer si le temps d’arrêt est acceptable. Dans la mesure du possible, exécutez la migration en période creuse. Si le temps d’arrêt imposé par la migration hors connexion n’est pas acceptable, optez pour une migration en ligne.
Pour plus d’informations sur les migrations en ligne, consultez Migrer MongoDB vers l’API Azure Cosmos DB pour MongoDB en ligne.
Pour plus d’informations sur les migrations hors connexion, consultez Migrer MongoDB vers l’API Azure Cosmos DB pour MongoDB hors connexion.