Déployer Atlas Live Migration pour migrer MongoDB vers MongoDB Atlas

Last reviewed 2023-05-08 UTC

Ce document explique comment déployer l'architecture présentée dans Utiliser Atlas Live Migration pour migrer MongoDB vers MongoDB Atlas.

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.

Architecture

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

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

Dans le schéma, 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. Pour en savoir plus sur l'architecture, consultez la page Utiliser Atlas Live Migration pour migrer MongoDB vers 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

Coûts

Le déploiement de cette architecture utilise les composants facturables suivants de Google Cloud :

Compute Engine

Pour déployer cette architecture, 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, puis consultez les informations tarifaires de Google Cloud. 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é ce déploiement, 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 la console Google Cloud, 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 ce déploiement, créez un projet au lieu d'en sélectionner un existant. Une fois le déploiement terminé, vous pouvez supprimer le projet afin de supprimer 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. Découvrez comment vérifier si la facturation est activée sur un projet.

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

Pour démarrer le déploiement, vous devez installer l'ensemble d'instances dupliquées MongoDB sur Google Cloud. Cette base de données sert de base de données source. Vous allez ensuite vérifier si votre base de données source répond à toutes les conditions préalables requises. Cette vérification de condition préalable vous permet de vous préparer à la migration dans un environnement de production. Même si une instance dupliquée MongoDB existe déjà dans votre environnement de production, vous devez toujours vérifier les conditions préalables.

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.

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 une connexion 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 : nom 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 fournissez une phrase secrète, 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 maintenant 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. Bien que l'ensemble d'instances dupliquées MongoDB source que vous avez installé dans le cadre de ce déploiement soit conforme à la version requise, vous devez toujours vérifier les conditions préalables dans un environnement de production. Les vérifications des conditions préalables sont décrites dans la documentation Atlas.

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 les éléments suivants :
- 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.

Après avoir vérifié les conditions préalables et effectué les modifications nécessaires, terminez les configurations et redémarrez votre base de données, comme décrit dans la section suivante.

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

Pour activer l'authentification, vous devez créer des fichiers de clé et un administrateur. Dans un environnement de production, vous pouvez 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 les éléments suivants :
- 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 une connexion SSH pour vous connecter à la VM et modifier le propriétaire et 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 du fichier mongod.conf :
```
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).

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.

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 .
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 l'exemple de commande suivant :
```
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 l'interface système mongo sur l'une des instances en cours d'exécution 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 de la validation. 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 une connexion 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 maintenant vérifié que Atlas Live Migration a migré automatiquement toutes les données d'origine de la source et toutes les modifications en cours vers la source.

Tester le cluster cible Atlas

Dans un environnement de production, il est important de tester les applications qui accèdent aux bases de données cibles afin de vous assurer qu'elles fonctionnent correctement. 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 des stratégies précédentes n'est viable, 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. Pour éviter les incohérences ou les données superflues dans la base de données cible, les données de test doivent être supprimées une fois les tests terminés.

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

Les sections suivantes expliquent comment éviter les frais futurs pour votre projet Google Cloud et pour les ressources MongoDB que vous avez utilisées dans ce déploiement.

Supprimer le projet Google Cloud

Pour éviter que les ressources utilisées dans ce déploiement ne soient facturées sur votre compte Google Cloud, vous pouvez supprimer le projet Google Cloud.

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.
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.