Migrer de MongoDB vers MongoDB Atlas à l'aide d'Atlas Live Migration

Last reviewed 2023-03-01 UTC

Ce tutoriel décrit et met en œuvre la migration d'un ensemble d'instances dupliquées MongoDB autogéré contenant des bases de données vers un cluster entièrement géré dans MongoDB Atlas à l'aide du service de migration à chaud de MongoDB (Atlas Live Migration).

Il est destiné aux architectes, administrateurs et ingénieurs de bases de données qui souhaitent disposer d'un service MongoDB entièrement hébergé, ou qui sont chargés de migrer des bases de données MongoDB d'un ensemble d'instances dupliquées MongoDB vers un cluster MongoDB Atlas.

Objectifs

Configurer votre source autogérée en créant et en chargeant des documents dans un exemple d'ensemble d'instances dupliquées MongoDB
Configurer un cluster cible de migration dans MongoDB Atlas
Utiliser Atlas Live Migration pour migrer une base de données de votre ensemble d'instances dupliquées MongoDB autogéré vers un cluster MongoDB Atlas entièrement géré
Comprendre et sélectionner les stratégies de test, de bascule et de remplacement

Ce tutoriel utilise un ensemble d'instances dupliquées MongoDB comme source. La migration d'un cluster MongoDB segmenté vers MongoDB Atlas n'est pas traitée dans ce tutoriel. La différence architecturale entre un ensemble d'instances dupliquées MongoDB et un cluster MongoDB segmenté est expliquée dans un article de la section Stack Exchange : Database Administrators (administrateurs de bases de données).

Pour effectuer la migration de ce tutoriel, vous utiliserez Atlas Live Migration, et non l'utilitaire Atlas mongomirror. L'utilitaire mongomirror nécessite l'installation d'un agent sur l'environnement MongoDB source et fonctionne à un niveau d'abstraction inférieur.

La configuration de migration utilisée dans ce tutoriel est une migration homogène avec une sémantique de copie. Les données ne sont pas transformées pendant la migration, et aucune consolidation ni aucun repartitionnement des données n'a lieu. Vous pouvez mettre en œuvre des fonctionnalités autres qu'une sémantique de copie avec une technologie d'intégration telle que Striim.

Dans ce tutoriel, la migration est une migration à sens unique d'un ensemble d'instances dupliquées MongoDB source vers un cluster MongoDB Atlas cible. Une fois la bascule de l'ensemble d'instances dupliquées MongoDB source vers le cluster cible terminée, les bases de données sources ne sont pas mises à jour selon les modifications apportées au cluster cible. Ainsi, si vous mettez en œuvre cette solution dans un environnement de production, vous ne pouvez pas basculer vos applications vers des bases de données sources à jour dans le cadre d'un remplacement. Pour en savoir plus sur les processus de remplacement, consultez la page Migration de bases de données : concepts et principes (partie 2).

Architecture de migration

Le schéma suivant illustre l'architecture de déploiement que vous allez créer dans ce tutoriel.

Serveurs MongoDB sur Compute Engine avec le chemin de migration du serveur principal vers MongoDB Atlas.

La flèche représente le chemin de migration des données de l'ensemble d'instances dupliquées MongoDB source s'exécutant sur Compute Engine vers le cluster cible s'exécutant dans MongoDB Atlas sur Google Cloud.

L'architecture de déploiement contient les composants suivants :

Base de données source : ensemble d'instances dupliquées MongoDB autogéré s'exécutant sur trois instances Compute Engine
Base de données cible : cluster MongoDB Atlas entièrement géré
Service de migration : configuration Atlas Live Migration pour migrer des données de la source vers la cible

Bien que ce tutoriel utilise un ensemble d'instances dupliquées MongoDB autogéré sur des instances Compute Engine, vous pouvez également déployer un ensemble d'instances dupliquées MongoDB source dans un centre de données sur site ou un autre environnement cloud.

Atlas Live Migration est compatible avec une approche de migration de base de données sans interruption. Pendant la migration à partir de l'ensemble d'instances dupliquées MongoDB source, vos applications peuvent toujours accéder aux bases de données sources sans impact. Une fois le chargement initial terminé, Atlas Live Migration migre les modifications au fur et à mesure qu'elles se produisent après le démarrage de la migration.

Pour effectuer la bascule de la base de données source vers le cluster cible après la migration de l'ensemble de données initial, procédez comme suit :

Suspendez l'accès en écriture à la base de données source.
Attendez que Atlas Live Migration capture les modifications restantes et les applique à la base de données cible.
Exécutez la bascule dans Atlas Live Migration.
Arrêtez la base de données source.

Une fois que toutes les données sont migrées, Atlas Live Migration vous le signale sur la ligne d'état de progression dans l'interface utilisateur. À ce stade, la migration des données est terminée et les systèmes d'application peuvent commencer à accéder au cluster cible en tant que nouveau système d'enregistrement.

Coûts

Ce tutoriel utilise les composants facturables Google Cloud suivants :

Compute Engine

Pour suivre ce tutoriel, vous ne pouvez pas utiliser la version gratuite de MongoDB Atlas. Les types de machines disponibles dans la version gratuite ne sont pas compatibles avec Atlas Live Migration. Le type de machine minimal requis (M10 au moment de la rédaction de ce document) a un coût de service horaire dans MongoDB Atlas. Pour générer une estimation de prix, accédez à la page des tarifs de MongoDB, cliquez sur Google Cloud Platform, puis suivez les instructions. Si vous mettez en œuvre cette migration en production, nous vous recommandons d'utiliser la version hébergée standard de MongoDB Atlas.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

Accéder au sélecteur de projet
Vérifiez que la facturation est activée pour votre projet Google Cloud.

Créer un ensemble d'instances dupliquées MongoDB autogéré

Commencez par installer l'ensemble d'instances dupliquées MongoDB sur Google Cloud. Cette base de données sert de base de données source. Ensuite, vérifiez si votre base de données source répond à toutes les conditions préalables requises.

Une fois la vérification des conditions préalables terminée, vous devez activer l'authentification et redémarrer l'instance MongoDB source. Enfin, pour tester la migration, vous devez ajouter un exemple d'ensemble de données à l'instance MongoDB source qui est migrée vers la base de données cible.

Installer l'ensemble d'instances dupliquées MongoDB

Dans Google Cloud Marketplace, accédez à l'installation de l'ensemble d'instances dupliquées MongoDB sur Compute Engine. Au moment de la rédaction de ce document, la version est MongoDB 4.0.

Accéder à MongoDB dans Cloud Marketplace
Cliquez sur Lancer. Étant donné que plusieurs API Google Cloud sont activées, le processus de lancement peut prendre un certain temps.

Si vous disposez des autorisations pour plusieurs projets, la liste des projets s'affiche. Sélectionnez le projet pour votre installation MongoDB.

Un ensemble d'instances dupliquées MongoDB est déployé sur un ensemble d'instances Compute Engine selon un modèle Deployment Manager.
Acceptez tous les paramètres de configuration par défaut.
Cliquez sur Déployer.
Dans la console Google Cloud, activez Cloud Shell.

Activer Cloud Shell

En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Utilisez ssh pour vous connecter à l'instance Compute Engine qui exécute le serveur principal MongoDB :
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Remplacez les éléments suivants :
- MONGODB_VM_NAME : nom de l'instance dupliquée principale de l'ensemble d'instances dupliquées MongoDB
- PROJECT_ID : ID de votre projet Google Cloud.
- ZONE_OF_VM : zone dans laquelle réside votre instance de machine virtuelle (VM)
  
  Pour en savoir plus, consultez la page Zones géographiques et régions.
Si une clé SSH est générée, le système vous demande une phrase secrète. Si vous ne souhaitez pas fournir de phrase secrète, appuyez sur Enter. Si vous en fournissez une, notez-la pour vous y référer ultérieurement.

Si vous ne parvenez pas à vous connecter à l'aide de Cloud Shell, cliquez sur SSH to a servers tier VM (Se connecter en SSH à une VM de niveau serveur) dans Deployment Manager.
Lancez l'interface système mongo :
```
mongo
```
Répertoriez les bases de données existantes :
```
show dbs
```
Le résultat ressemble à ce qui suit :
```
admin   0.000GB
config  0.000GB
local   0.000GB
```
Laissez l'interface système mongo ouverte pour les commandes à venir.

Vous avez créé votre ensemble d'instances dupliquées MongoDB, y avez accédé et avez vérifié qu'il est opérationnel.

Vérifier les conditions préalables pour la base de données source

Atlas Live Migration nécessite que l'ensemble d'instances dupliquées MongoDB source respecte des critères de configuration spécifiques, ou conditions préalables. Les vérifications sont décrites dans la présentation de la migration Atlas et dans la documentation Atlas. Les commandes suivantes sont dérivées de ces ressources. Une fois ces conditions préalables remplies et les modifications nécessaires effectuées, votre base de données source nécessite des configurations supplémentaires et un redémarrage.

Pour vérifier si toutes les conditions préalables sont remplies, procédez comme suit :

Dans l'interface système mongo, vérifiez que la version de MongoDB est la version 2.6 ou une version ultérieure. Dans une instance de base de données de production, ouvrez l'interface système mongo, connectez-vous au serveur MongoDB à l'aide d'une connexion SSH, puis exécutez cette commande pour déterminer la version.
```
db.version()
```
La sortie affiche la version. Si votre version est antérieure à la version 2.6, vous devez suivre les instructions de mise à niveau.
Vérifiez que votre déploiement actuel est un ensemble d'instances dupliquées MongoDB :
```
rs.status()
```
La sortie correspond à l'état de l'ensemble d'instances dupliquées MongoDB. La sortie suivante montre qu'une instance MongoDB a démarré sans que l'ensemble d'instances dupliquées MongoDB ne soit activé.
```
{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}
```
En pareil cas, arrêtez l'instance MongoDB, puis redémarrez-la après avoir activé l'ensemble d'instances dupliquées MongoDB. Si vous disposez d'une instance autonome de MongoDB, mettez à niveau l'instance MongoDB vers un ensemble d'instances dupliquées MongoDB.
Vérifiez que l'authentification est activée sur votre cluster source en vous connectant :
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Remplacez l'élément suivant :
- YOUR_ADMIN_USERNAME : nom d'utilisateur de l'administrateur de votre déploiement
L'authentification n'est pas activée pour l'ensemble d'instances dupliquées MongoDB créé précédemment.

Si l'authentification n'est pas activée, vous devez suivre les instructions permettant de l'activer. Voici un exemple de commande permettant d'activer l'authentification, avec un exemple de nom d'utilisateur et de mot de passe :
```
use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "myUserAdminPassword",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase", "clusterMonitor" ]
  }
)
```
Une fois l'authentification activée, le rôle MongoDB clusterMonitor est requis pour exécuter rs.status(). La commande précédente spécifie ce rôle.
Vérifiez que l'administrateur dispose des rôles appropriés pour la version de l'ensemble d'instances dupliquées MongoDB. Pour obtenir la liste des rôles qui correspondent à une version particulière, consultez la discussion sur la sécurité des clusters sources dans la documentation d'Atlas Live Migration.
```
use admin
db.getUser("YOUR_ADMIN_USERNAME")
```
Le nom d'utilisateur doit être placé entre guillemets.
(Facultatif) Si votre déploiement MongoDB est basé sur une version antérieure à la version 4.2, il contient des index dont les clés dépassent la limite de clé d'index de 1 024 octets. Dans ce cas, définissez le paramètre de serveur MongoDB failIndexKeyTooLong sur "false" avant de lancer la procédure de migration Atlas Live Migration.

Activer l'authentification et redémarrer l'ensemble d'instances dupliquées MongoDB

Pour activer l'authentification, vous devez obligatoirement fournir des fichiers de clé en plus de créer un administrateur. Les étapes suivantes montrent comment créer des fichiers de clé manuellement. Dans un environnement de production, vous pouvez envisager d'utiliser des scripts pour automatiser ce processus.

Dans Cloud Shell, créez un fichier de clé :
```
openssl rand -base64 756 > PATH_TO_KEY_FILE
```
Remplacez l'élément suivant :
- PATH_TO_KEY_FILE : emplacement où votre clé SSH est stockée ; par exemple /etc/mongo-key
Activez l'autorisation pour chacune des trois VM :
1. Copiez le fichier de clé sur la VM :
```
gcloud compute copy-files PATH_TO_KEY_FILE NAME_OF_THE_VM:PATH_TO_KEY_FILE --zone=ZONE_OF_VM
```
  Remplacez les éléments suivants :
  - NAME_OF_THE_VM : nom de l'une des VM exécutant une instance dupliquée de l'ensemble d'instances dupliquées
  - ZONE_OF_VM : zone Google Cloud dans laquelle se trouve la VM, référencée dans NAME_OF_THE_VM
2. Utilisez ssh pour vous connecter à la VM et modifier le propriétaire ainsi que les autorisations d'accès au fichier de clé :
```
sudo chown mongodb:mongodb PATH_TO_KEY_FILE

sudo chmod 400 PATH_TO_KEY_FILE
```
3. Dans l'éditeur de texte de votre choix, ouvrez le fichier mongod.conf en mode Édition. Si vous souhaitez réécrire des modifications, vous devrez peut-être utiliser la commande sudo pour démarrer votre éditeur de texte.
4. Modifiez la section security comme suit :
```
security:
  authorization: enabled
  keyFile: PATH_TO_KEY_FILE
```
5. Redémarrez l'instance dupliquée :
```
sudo service mongod restart
```
Vérifiez que vous pouvez vous connecter à l'instance principale de l'ensemble d'instances dupliquées MongoDB :
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```

Insérer des exemples de données

Au cours des étapes suivantes, vous allez insérer des exemples de données dans la base de données source, puis vérifier que les documents ont bien été insérés :

Dans Cloud Shell, utilisez ssh pour vous connecter à l'instance Compute Engine principale MongoDB :
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Vous devrez peut-être fournir la phrase secrète pour la clé SSH.
Démarrez l'interface système mongo :
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Indiquez le mot de passe que vous avez spécifié lors de la création du nom d'utilisateur de l'administrateur.
Créez une base de données :
```
use migration
```
Créez une collection :
```
db.createCollection("source")
```
Vérifiez que la collection est vide :
```
db.source.count()
```

Ajoutez les cinq documents suivants comme ensemble de données initial :

db.source.insert({"document_number": 1})
db.source.insert({"document_number": 2})
db.source.insert({"document_number": 3})
db.source.insert({"document_number": 4})
db.source.insert({"document_number": 5})

La sortie de chacune de ces commandes ressemble à ce qui suit :

WriteResult({ "nInserted" : 1 })

Vérifiez que vous avez bien ajouté les cinq documents pour la migration de la collection. Le résultat doit être 5.
```
db.source.count()
```

Une fois la migration de la base de données configurée et démarrée, ces documents sont transférés vers le cluster cible dans MongoDB Atlas.

Créer un cluster dans MongoDB Atlas

Un ensemble d'instances dupliquées MongoDB est appelé cluster dans MongoDB Atlas. Si aucun cluster n'est configuré comme base de données cible, suivez les étapes décrites dans cette section. Ces étapes sont basées sur la documentation MongoDB. Si vous avez déjà configuré un cluster en tant que base de données cible, vous pouvez ignorer cette section.

Dans Cloud Marketplace, accédez à la page MongoDB Atlas – Installation de version gratuite.

Accéder à MongoDB Atlas sur Marketplace
Cliquez sur Accéder au site MongoDB pour vous inscrire.
Cliquez sur Lancer votre premier cluster.
Saisissez les informations demandées, puis cliquez sur Commencer gratuitement. Notez les informations que vous avez fournies.
Cliquez sur Options de configuration avancées.
Pour les valeurs Fournisseur cloud et Région, sélectionnez Google Cloud Platform et Iowa (us-central1).
Cliquez sur l'onglet Niveau de cluster, puis sélectionnez M10.
Cliquez sur l'onglet Paramètres supplémentaires, sélectionnez MongoDB 4.0 ou MongoDB 4.2, puis désactivez la sauvegarde.
Cliquez sur Créer un cluster.

Attendez la fin de la création du cluster. Notez que le nom du projet est Project 0 (avec espace) et que le nom du cluster est Cluster0 (sans espace).
Remarque : Des captures d'écran à jour de ces processus sont incluses dans la documentation de MongoDB Atlas.

Le cluster cible est configuré et s'exécute dans MongoDB Atlas.

Tester le basculement du cluster MongoDB Atlas

Une fois la migration terminée, le cluster de MongoDB Atlas exécute un redémarrage progressif. Chacun des membres du cluster redémarre à son tour. Pour vous assurer que ce processus fonctionne, testez le basculement en suivant les étapes de la documentation MongoDB.

Démarrer la migration à chaud

Pour migrer les données de la base de données source vers la base de données cible, procédez comme suit :

Connectez-vous à MongoDB Atlas.
Accédez à la page Clusters, puis sélectionnez le cluster vers lequel vous souhaitez effectuer la migration.
Dans le volet du cluster cible (Cluster 0), cliquez sur le bouton représentant des points de suspension ().
Sélectionnez Migrer les données vers ce cluster.
Dans la fenêtre qui s'ouvre, vérifiez les informations. Lorsque vous êtes prêt à effectuer la migration, cliquez sur Je suis prêt à migrer.

Une fenêtre contenant les instructions de migration des données s'affiche. Les adresses IP répertoriées doivent être en mesure d'accéder à l'ensemble d'instances dupliquées MongoDB. Si vous n'avez pas créé de règle de pare-feu pour ces adresses, utilisez Cloud Shell pour ajouter une règle de pare-feu basée sur cet exemple de commande :
```
gcloud compute firewall-rules create "allow-mongodb-atlas" --allow=tcp:27027 --source-ranges="35.170.231.208/32,3.92.230.111/32,3.94.238.78/32,54.84.208.96/32" --direction=INGRESS
```
Dans le champ Nom d'hôte:Port de l'instance principale de votre ensemble d'instances dupliquées, saisissez l'adresse IP et le port de l'instance principale de l'ensemble d'instances dupliquées MongoDB. Par exemple : IP_ADDRESS:PORT_FOR_PRIMARY.
1. Pour déterminer l'instance principale, exécutez la commande suivante dans le shell mongo sur l'une des instances exécutées dans votre projet Google Cloud :
  
  rs.isMaster().primary
2. Pour rechercher l'adresse IP externe correspondante, accédez à la page Instances de VM de Compute Engine. Le port MongoDB standard est 27017.
Saisissez le nom d'utilisateur et le mot de passe de l'administrateur de votre ensemble d'instances dupliquées MongoDB.

Conservez les valeurs par défaut de tous les autres paramètres.
Cliquez sur Valider, puis effectuez l'une des opérations suivantes :
- Si la validation réussit, cliquez sur Démarrer la migration.
- Si la validation échoue, suivez les instructions fournies pour résoudre le problème. Par exemple, si MongoDB Atlas ne peut pas se connecter à l'ensemble d'instances dupliquées MongoDB, il fournit les adresses IP à partir desquelles MongoDB Atlas tente de se connecter. Pour ces adresses, ajoutez une règle de pare-feu qui autorise le trafic TCP sur le port 27017 pour les serveurs de l'ensemble d'instances dupliquées MongoDB.
L'écran MongoDB Atlas affiche la progression effectuée. Attendez que le message Initial Sync Complete! (Synchronisation initiale terminée) s'affiche dans la barre de progression.

Le chargement initial de l'ensemble d'instances dupliquées MongoDB est maintenant terminé. L'étape suivante consiste à vérifier que le chargement initial a abouti.

Une fois la migration initiale terminée, MongoDB Atlas fournit une estimation du nombre d'heures restantes jusqu'à ce que vous deviez effectuer la bascule vers le cluster cible. Vous pouvez également recevoir un e-mail de MongoDB vous indiquant le nombre d'heures restantes, la possibilité de prolonger ce délai et un avertissement indiquant que si une bascule finale n'est pas effectuée dans le délai imparti, la migration sera annulée.

Vérifier la migration de la base de données

Il est important de concevoir et de mettre en œuvre une stratégie de vérification de migration de base de données pour vérifier que la migration a réussi. La stratégie de vérification dépend de votre cas d'utilisation spécifique, mais nous vous recommandons d'effectuer les vérifications suivantes :

Vérification d'exhaustivité : vérifiez que l'ensemble de documents initial a bien été migré à partir des bases de données sources (chargement initial).
Vérification dynamique : vérifiez que les modifications apportées aux bases de données sources sont transférées vers les bases de données cibles (migration en cours).

Tout d'abord, vérifiez que le chargement initial a réussi :

Dans MongoDB Atlas, cliquez sur Clusters.
Cliquez sur Collections.
Vérifiez qu'une base de données nommée migrations existe et que la collection nommée source comporte cinq documents.

Ensuite, vérifiez que les modifications en cours apportées aux bases de données sources sont répercutées dans les bases de données cibles :

Dans Cloud Shell, utilisez ssh pour vous connecter à la VM principale de l'ensemble d'instances dupliquées MongoDB source.
Démarrez l'interface système mongo. mongo

Insérez un autre document :

use migration
db.source.insert({"document_number": 6})

Sur la page Collections MongoDB Atlas de la collection de migration, cliquez sur Actualiser pour observer qu'un document est ajouté à la collection source.

Vous avez vérifié que toutes les données d'origine provenant de la source et toutes les modifications en cours apportées à la source sont automatiquement transférées vers la cible par Atlas Live Migration.

Tester le cluster cible Atlas

Dans un environnement de production, les tests sont essentiels. Il est nécessaire de tester les applications qui accèdent aux bases de données cibles afin de garantir leur bon fonctionnement. Cette section traite de plusieurs stratégies de test.

Tester des applications avec une base de données cible lors d'une migration

Comme le montre la section précédente, vous pouvez effectuer des tests d'application lorsque la migration d'une base de données est en cours. Cette approche peut fonctionner si les applications ne modifient pas la cible de telle sorte que cela génère un conflit avec les données migrées à partir des bases de données sources. Le choix de cette approche dépend de votre environnement et de vos dépendances. Si l'application de test écrit des données dans la base de données cible, elle peut entrer en conflit avec la migration en cours.

Tester des applications avec une base de données cible temporaire

Si vous ne pouvez pas tester des applications lors d'une migration de base de données de production, vous pouvez migrer les données vers des bases de données cibles temporaires que vous n'utilisez que pour des tests, puis supprimer ces bases de données après une migration de test.

Cette méthode consiste à arrêter la migration de test à un moment donné (pour imiter la fin de la migration de la base de données) et à tester les applications par rapport à ces bases de données de test. Une fois les tests terminés, vous supprimez les bases de données cibles et démarrez la migration de la base de données de production pour migrer les données vers des bases de données cibles permanentes. L'avantage de cette stratégie est qu'il est possible de lire ou d'écrire des données sur les bases de données cibles, car elles ne sont utilisées que pour les tests.

Tester les applications avec une base de données cible une fois la migration terminée

Si aucune de ces deux premières stratégies n'est envisageable, la stratégie restante consiste à tester l'application sur la base de données une fois la migration terminée. Une fois que toutes les données se trouvent dans les bases de données cibles, testez les applications avant de les mettre à la disposition des utilisateurs. Si les tests incluent l'écriture de données, il est important que les données de test, et non les données de production, soient écrites, afin d'éviter toute incohérence des données de production. Les données de test doivent être supprimées une fois les tests terminés pour éviter toute incohérence et toute redondance des données dans la base de données cible.

Nous vous recommandons de sauvegarder les bases de données cibles avant de les ouvrir à un accès en production par les systèmes d'application. Cette étape permet de s'assurer que vous pouvez recréer un point de départ cohérent si nécessaire.

Basculer de l'ensemble d'instances dupliquées MongoDB source vers le cluster cible

Une fois que vous avez terminé les tests et vérifié que les modifications en cours sont répercutées dans la base de données cible, vous pouvez planifier la bascule.

Tout d'abord, vous devez arrêter les modifications apportées à la base de données source afin que Atlas Live Migration puisse drainer les modifications qui n'ont pas encore été migrées vers la cible. Une fois que toutes les modifications ont été capturées dans la cible, vous pouvez lancer le processus de bascule d'Atlas Live Migration. Une fois ce processus terminé, vous pouvez faire basculer les clients de la base de données source vers la base de données cible.

Dans MongoDB Atlas, cliquez sur Clusters.
Dans le volet Cluster0, cliquez sur Se préparer à la bascule. Une explication détaillée du processus de bascule et une chaîne de connexion au cluster cible s'affichent.
Cliquez sur Basculer.

Une fois la migration terminée, le message Success! Your cluster migration is complete (Opération réussie ! La migration de votre cluster est terminée) s'affiche.

Vous avez migré avec succès votre ensemble d'instances dupliquées MongoDB vers un cluster MongoDB Atlas.

Préparer une stratégie de remplacement

Une fois la bascule terminée, le cluster cible devient le système d'enregistrement. Les bases de données sources sont obsolètes. Elles seront supprimées à terme. Cependant, vous pouvez vouloir revenir aux bases de données sources en cas de défaillances graves des nouvelles bases de données cibles. Par exemple, une défaillance peut se produire si la logique métier d'une application n'est pas exécutée lors des tests, et ne fonctionne pas correctement par la suite. Une autre défaillance peut se produire lorsque le comportement en matière de performances ou de latence ne correspond pas aux bases de données sources et génère des erreurs.

Pour éviter toute perte après de telles défaillances, vous pouvez vouloir maintenir les bases de données sources d'origine à jour avec les modifications de la base de données cible. Atlas Live Migration ne fournit pas de mécanisme de remplacement. Pour en savoir plus sur les stratégies de remplacement, consultez la page Migration de bases de données : concepts et principes (partie 2).

Effectuer un nettoyage

Supprimer le projet Google Cloud

Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, vous pouvez supprimer le projet Google Cloud que vous avez créé pour ce tutoriel.

Attention : La suppression d'un projet aura les effets suivants :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches de ce document, lorsque vous le supprimez, vous supprimez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

Dans la console Google Cloud, accédez à la page Gérer les ressources.
Accéder à la page Gérer les ressources
Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Mettre en veille ou arrêter le cluster MongoDB Atlas

Pour éviter que des frais supplémentaires ne soient appliqués pour l'utilisation du cluster MongoDB Atlas, vous devez le mettre en veille ou l'arrêter. Pour en savoir plus sur les implications en termes de facturation, consultez la page Suspendre ou arrêter un cluster.

Étape suivante

Consultez le contenu concernant la migration des données Google Cloud.
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.