Migrazione da MongoDB ad MongoDB Atlas utilizzando Atlas Live Migration

Last reviewed 2023-03-01 UTC

Questo tutorial descrive e implementa una migrazione da un set di repliche MongoDB autogestito, che contiene database a un cluster completamente gestito in MongoDB Atlas, utilizzando Atlas Live Migration Service (Atlas Live Migration) di MongoDB.

Questo tutorial è destinato a architetti di database, amministratori di database e tecnici di database interessati a un servizio MongoDB completamente ospitato o responsabili del trasferimento dei database MongoDB in una replica MongoDB impostata su un cluster MongoDB Atlas.

Obiettivi

Configura l'origine autogestita creando e caricando documenti in un set di repliche MongoDB di esempio.
Configura un cluster di destinazione della migrazione in MongoDB Atlas.
Utilizza Atlas Live Migration per eseguire la migrazione di un database dal tuo set di repliche MongoDB autogestite a un cluster MongoDB Atlas completamente gestito.
Comprendi e seleziona le strategie di test, cutover e fallback.

Questo tutorial utilizza un set di repliche MongoDB come origine. La migrazione di un cluster MongoDB con sharding ad MongoDB Atlas non è trattata in questo tutorial, La differenza di architettura tra un set di repliche MongoDB e un cluster MongoDB con sharding è spiegata in questo post su Stack Exchange: Database Administrator.

Per completare la migrazione per questo tutorial, utilizzi Atlas Live Migration, non l'utilità Atlas mongomirror. L'utilità mongomirror richiede l'installazione di un agente nell'ambiente di origine MongoDB e opera a un livello di astrazione inferiore.

La configurazione della migrazione in questo tutorial è una migrazione omogenea con una semantica di copia. I dati non vengono trasformati durante la migrazione e non avvengono un consolidamento dei database o un ripristino dei dati. Puoi implementare funzionalità oltre la semantica della copia con tecnologia di integrazione come Striim.

La migrazione in questo tutorial è una migrazione unidirezionale da una replica MongoDB di origine impostata a un cluster MongoDB Atlas di destinazione. Una volta completato il cutover dall'origine della replica MongoDB sul cluster di destinazione, i database di origine non vengono aggiornati con le modifiche al cluster di destinazione. Pertanto, se implementi questa soluzione in un ambiente di produzione, non puoi passare le tue applicazioni a database di origine aggiornati in un fallback. Per ulteriori informazioni sui processi di fallback, consulta Migrazione dei database: concetti e principi (Parte 2).

Architettura di migrazione

Il seguente diagramma mostra l'architettura di deployment creata in questo tutorial.

Server MongoDB su Compute Engine con il percorso di migrazione da quello principale a MongoDB Atlas.

La freccia rappresenta il percorso di migrazione dei dati dal set di repliche di origine MongoDB in esecuzione su Compute Engine al cluster di destinazione in esecuzione su MongoDB Atlas su Google Cloud.

L'architettura di deployment contiene i seguenti componenti:

Database di origine: un set di repliche autogestite di MongoDB in esecuzione su tre istanze di Compute Engine
Database di destinazione: un cluster MongoDB Atlas completamente gestito
Servizio di migrazione:una configurazione di Atlas Live Migration per la migrazione di dati dall'origine al target

Anche se questo tutorial utilizza un set di repliche MongoDB autogestito sulle istanze di Compute Engine, puoi anche eseguire il deployment di un set di repliche MongoDB di origine in un data center on-premise o in un altro ambiente cloud.

Atlas Live Migration supporta un approccio di migrazione dei database con zero tempi di inattività. Durante la migrazione dal set di repliche MongoDB di origine, le tue applicazioni possono comunque accedere ai database di origine senza alcun impatto. Dopo il caricamento iniziale, Atlas Live Migration esegue la migrazione delle modifiche man mano che si verificano dopo l'avvio della migrazione.

Per eseguire il cutover dal database di origine al cluster di destinazione dopo la migrazione del set di dati iniziale, segui questi passaggi:

Sospendi l'accesso in scrittura al database di origine.
Attendi che Atlas Live Migration acquisisca le modifiche rimanenti e le applichi al database di destinazione.
Eseguire il cutover in Atlas Live Migration.
Arresta il database di origine.

Una volta eseguita la migrazione di tutti i dati, Atlas Live Migration ti avvisa nella riga dello stato di avanzamento dell'interfaccia utente. A questo punto, la migrazione dei dati è completa e i sistemi delle applicazioni possono iniziare ad accedere al cluster di destinazione come nuovo sistema di registrazione.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Compute Engine

Per completare questo tutorial, non puoi utilizzare il livello gratuito di MongoDB Atlas. I tipi di macchina disponibili nel livello gratuito non supportano Atlas Live Migration. Il tipo di macchina minimo richiesto (M10 al momento della stesura di questo documento) ha un costo del servizio orario in MongoDB Atlas. Per generare una stima dei prezzi, vai a Prezzi di MongoDB Atlas, fai clic su Google Cloud Platform e segui le istruzioni. Se implementi questa migrazione in produzione, ti consigliamo di utilizzare la versione ospitata standard di MongoDB Atlas.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

Vai al selettore progetti
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

Creazione di un set di repliche MongoDB autogestito

Innanzitutto, installa il set di repliche MongoDB su Google Cloud. Questo database è il tuo database di origine. Quindi, controlla se il tuo database di origine soddisfa tutte le precondizioni richieste.

Dopo aver completato il controllo delle precondizioni, devi abilitare l'autenticazione e riavviare l'istanza MongoDB di origine. Infine, per testare la migrazione, aggiungi un set di dati di esempio all'istanza MongoDB di cui viene eseguita la migrazione al database di destinazione.

Installa il set di repliche MongoDB

In Google Cloud Marketplace, vai all'installazione del set di repliche MongoDB su Compute Engine. Al momento della stesura di questo articolo, la versione attuale è MongoDB 4.0.

Vai a MongoDB in Cloud Marketplace
Fai clic su Launch . Poiché sono abilitate diverse API Google Cloud, il processo di lancio può richiedere un po' di tempo.

Se disponi delle autorizzazioni per più progetti, viene visualizzato un elenco di progetti. Seleziona il progetto per l'installazione di MongoDB.

Viene eseguito il deployment di un set di repliche MongoDB su un set di istanze Compute Engine in base a un modello Deployment Manager.
Accetta tutte le impostazioni di configurazione predefinite.
Fai clic su Esegui il deployment.
Nella console Google Cloud, attiva Cloud Shell.

Attiva Cloud Shell

Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
Utilizza ssh per accedere all'istanza di Compute Engine che esegue l'istanza principale di MongoDB:
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Sostituisci quanto segue:
- MONGODB_VM_NAME: il nome della replica principale del set di repliche MongoDB
- PROJECT_ID: il nome del tuo ID progetto Google Cloud
- ZONE_OF_VM: la zona in cui si trova la tua istanza di macchina virtuale (VM)
  
  Per maggiori informazioni, consulta Area geografica e regioni.
Se viene generata una chiave SSH, il sistema richiede una passphrase. Se non vuoi fornire una passphrase, premi Enter. Se ne fornisci uno, notalo come riferimento futuro.

Se non riesci a connetterti utilizzando Cloud Shell, fai clic su SSH su una VM a livello di server in Deployment Manager.
Avvia la shell mongo:
```
mongo
```
Elenca i database esistenti:
```
show dbs
```
L'output è simile al seguente:
```
admin   0.000GB
config  0.000GB
local   0.000GB
```
Tieni aperta la shell mongo per i comandi imminenti.

Hai creato e eseguito l'accesso al tuo set di repliche MongoDB e hai confermato che è operativo.

Verifica le condizioni preliminari per il database di origine

Atlas Live Migration richiede che il set di repliche MongoDB di origine soddisfi criteri di configurazione specifici o precondizioni. I controlli sono descritti nella panoramica sulla migrazione di Atlas e nella documentazione di Atlas. Da queste risorse derivano i seguenti comandi. Dopo aver verificato queste precondizioni e aver apportato le modifiche necessarie, il database di origine richiede altre configurazioni e un riavvio.

Per controllare se tutte le condizioni preliminari sono soddisfatte:

Nella shell mongo, verifica che la versione di MongoDB sia 2.6 o successiva. In un'istanza di database di produzione, apri la shell mongo, connettiti al server MongoDB utilizzando una connessione SSH, quindi esegui questo comando per determinare la versione.
```
db.version()
```
L'output mostra la versione. Se hai una versione precedente alla 2.6, devi seguire le istruzioni per l'upgrade.
Verifica che il tuo deployment attuale sia un set di repliche MongoDB:
```
rs.status()
```
L'output è uno stato per il set di repliche MongoDB. L'output seguente mostra che un'istanza MongoDB è stata avviata senza abilitare il set di repliche MongoDB.
```
{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}
```
In questo caso, arresta e riavvia l'istanza MongoDB con il set di repliche MongoDB abilitato. Se hai un'istanza autonoma di MongoDB, esegui l'upgrade dell'istanza MongoDB a un set di repliche MongoDB.
Verifica che l'autenticazione sia abilitata sul tuo cluster di origine accedendo:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Sostituisci quanto segue:
- YOUR_ADMIN_USERNAME: il nome utente dell'amministratore del deployment
L'autenticazione per il set di repliche MongoDB creata in precedenza non è abilitata.

Se l'autenticazione non è abilitata, devi seguire le istruzioni per abilitarla. Di seguito è riportato un comando di esempio per abilitare l'autenticazione, con un nome utente e una password di esempio:
```
use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "myUserAdminPassword",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase", "clusterMonitor" ]
  }
)
```
Dopo l'abilitazione dell'autenticazione, il ruolo MongoDB clusterMonitor è obbligatorio per eseguire rs.status(). Il comando precedente specifica questo ruolo.
Verifica che all'utente amministratore siano assegnati i ruoli appropriati per la versione del set di repliche MongoDB. Per un elenco dei ruoli che corrispondono a una determinata versione, consulta la discussione sulla sicurezza dei cluster di origine nella documentazione di Atlas Live Migration.
```
use admin
db.getUser("YOUR_ADMIN_USERNAME")
```
Il nome utente deve essere inserito tra virgolette.
(Facoltativo) Se il deployment di MongoDB si basa su una versione precedente alla 4.2, contiene indici con chiavi che superano il limite di chiavi di indice di 1024 byte. In questo caso, imposta il parametro del server MongoDB failIndexKeyTooLong su false prima di avviare la procedura di Atlas Live Migration.

Abilita l'autenticazione e riavvia il set di repliche MongoDB

Per attivare l'autenticazione, sono necessari i file della chiave oltre a creare un amministratore. I passaggi seguenti mostrano come creare manualmente i file delle chiavi. In un ambiente di produzione, potresti prendere in considerazione l'uso di script per automatizzare il processo.

In Cloud Shell, crea un file della chiave:
```
openssl rand -base64 756 > PATH_TO_KEY_FILE
```
Sostituisci quanto segue:
- PATH_TO_KEY_FILE: la posizione in cui è archiviata la chiave SSH, ad esempio /etc/mongo-key
Abilita l'autorizzazione per ciascuna delle tre VM:
1. Copia il file della chiave nella VM:
```
gcloud compute copy-files PATH_TO_KEY_FILE NAME_OF_THE_VM:PATH_TO_KEY_FILE --zone=ZONE_OF_VM
```
  Sostituisci quanto segue:
  - NAME_OF_THE_VM: il nome di una delle VM che eseguono una replica del set di repliche
  - ZONE_OF_VM: la zona Google Cloud in cui si trova la VM a cui si fa riferimento in NAME_OF_THE_VM
2. Utilizza ssh per accedere alla VM, modificare il proprietario e le autorizzazioni di accesso al file della chiave:
```
sudo chown mongodb:mongodb PATH_TO_KEY_FILE

sudo chmod 400 PATH_TO_KEY_FILE
```
3. Nell'editor di testo che preferisci, apri il file mongod.conf in modalità di modifica. Se vuoi riscrivere le modifiche, potresti dover utilizzare il comando sudo per avviare l'editor di testo.
4. Modifica la sezione security nel seguente modo:
```
security:
  authorization: enabled
  keyFile: PATH_TO_KEY_FILE
```
5. Riavvia la replica:
```
sudo service mongod restart
```
Verifica di poter accedere all'istanza principale del set di repliche MongoDB:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```

Inserisci dati di esempio

Nei seguenti passaggi, inserisci i dati di esempio nel database di origine, quindi verifica che i documenti siano stati inseriti correttamente:

In Cloud Shell, utilizza ssh per connetterti all'istanza Compute Engine principale di MongoDB:
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Potrebbe essere necessario fornire la passphrase per la chiave SSH.
Avvia la shell mongo:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Inserisci la password specificata al momento della creazione del nome utente dell'amministratore.
Crea un database:
```
use migration
```
Crea una raccolta:
```
db.createCollection("source")
```
Verifica che la raccolta sia vuota:
```
db.source.count()
```

Aggiungi i cinque documenti seguenti come set di dati iniziale:

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})

L'output per ciascuno di questi comandi è simile al seguente:

WriteResult({ "nInserted" : 1 })

Verifica di aver aggiunto correttamente i cinque documenti nella migrazione delle raccolte. Il risultato deve essere 5.
```
db.source.count()
```

Una volta configurata e avviata la migrazione del database, questi documenti vengono migrati al cluster di destinazione in MongoDB Atlas.

Creazione di un cluster in MongoDB Atlas

Un set di repliche MongoDB è chiamato cluster in MongoDB Atlas. Se non hai configurato un cluster come database di destinazione, segui i passaggi descritti in questa sezione. Questi passaggi si basano sulla documentazione di MongoDB. Se hai già configurato un cluster come database di destinazione, puoi saltare questa sezione.

In Cloud Marketplace, vai alla pagina MongoDB Atlas - Livello gratuito gratuita.

Vai a MongoDB Atlas su Marketplace
Fai clic su Visita il sito MongoDB per registrarti.
Fai clic su Avvia il primo cluster.
Inserisci le informazioni richieste e fai clic su Inizia gratuitamente. Prendi nota delle informazioni che hai fornito.
Fai clic su Opzioni di configurazione avanzate.
In Provider e regione Cloud, seleziona Google Cloud Platform e Iowa (us-central1).
Fai clic sulla scheda Livello cluster, quindi seleziona M10.
Fai clic sulla scheda Impostazioni aggiuntive, seleziona MongoDB 4.0 o MongoDB 4.2, quindi disattiva il backup.
Fai clic su Crea cluster.

Attendi il completamento della creazione del cluster. Tieni presente che il nome del progetto è Project 0 (con uno spazio vuoto) e il nome del cluster è Cluster0 (senza lo spazio vuoto).

Nota: gli screenshot aggiornati di questi processi sono inclusi nella documentazione di MongoDB Atlas.

Il cluster di destinazione è configurato e in esecuzione in MongoDB Atlas.

Test del failover del cluster MongoDB Atlas

Al termine della migrazione, il cluster in MongoDB Atlas esegue un riavvio continuativo. Ogni membro del cluster si riavvia a sua volta. Per assicurarti che questo processo funzioni, verifica il failover seguendo i passaggi nella documentazione di MongoDB.

Avvio della migrazione live

Per eseguire la migrazione dei dati dall'origine al database di destinazione:

Accedi a MongoDB Atlas.
Vai alla pagina Cluster, quindi seleziona il cluster in cui vuoi eseguire la migrazione.
Nel riquadro del cluster di destinazione (Cluster 0), fai clic sul pulsante con i puntini di sospensione .
Seleziona Esegui la migrazione dei dati a questo cluster.
Nella finestra che si apre, esamina le informazioni. Quando vuoi avviare la migrazione, fai clic su Sono pronto per la migrazione.

Viene visualizzata una finestra con le istruzioni per la migrazione dei dati. Gli indirizzi IP elencati devono essere in grado di accedere al set di repliche MongoDB. Se non hai creato una regola firewall per questi indirizzi, utilizza Cloud Shell per aggiungere una regola firewall in base a questo comando di esempio:
```
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
```
Nel campo Nome host:Porta dell'istanza principale del set di repliche, inserisci l'indirizzo IP e la porta per l'istanza principale del set di repliche MongoDB, ad esempio IP_ADDRESS:PORT_FOR_PRIMARY.
1. Per determinare l'istanza principale, esegui il comando seguente nella shell mongo in entrambe le istanze in esecuzione nel progetto Google Cloud:
  
  rs.isMaster().primary
2. Per cercare l'indirizzo IP esterno corrispondente, vai alla pagina Istanze VM di Compute Engine. La porta standard di MongoDB è 27017.
Inserisci il nome utente e la password amministratore del set di repliche MongoDB.

Lascia invariate tutte le altre impostazioni predefinite.
Fai clic su Convalida e procedi in uno dei seguenti modi:
- Se la convalida ha esito positivo, fai clic su Avvia migrazione.
- Se la convalida non va a buon fine, utilizza le istruzioni fornite. Ad esempio, se MongoDB Atlas non può connettersi al set di repliche MongoDB, fornisce gli indirizzi IP da cui MongoDB Atlas sta tentando di connettersi. Per questi indirizzi, aggiungi una regola firewall che consenta il traffico TCP sulla porta 27017 per i server del set di repliche MongoDB.
La schermata MongoDB Atlas mostra i progressi compiuti. Attendi il messaggio Sincronizzazione iniziale completata nella barra di avanzamento.

Il carico iniziale dal set di repliche MongoDB è ora completo. Il passaggio successivo consiste nel verificare che il caricamento iniziale sia riuscito.

Al termine della migrazione iniziale, MongoDB Atlas fornisce una stima del numero di ore rimanenti prima di effettuare il cutover al cluster di destinazione. Potresti anche ricevere da MongoDB un'email che ti fornisce il numero di ore rimanenti, la possibilità di estendere l'intervallo oltre al limite impostato e un avviso che ti informa che se non verrà effettuata una migrazione finale entro il termine indicato, la migrazione verrà annullata.

Verifica della migrazione del database

È importante progettare e implementare una strategia di verifica della migrazione del database per confermare che la migrazione del database sia riuscita. Sebbene la strategia di verifica particolare dipende dal tuo caso d'uso specifico, ti consigliamo di eseguire i controlli riportati di seguito:

Verifica della completezza. Verifica che la migrazione del set di documenti iniziale sia stata eseguita dai database di origine (caricamento iniziale).
Controllo dinamico. Verifica che le modifiche nei database di origine vengano trasferite ai database di destinazione (migrazione in corso).

Innanzitutto, verifica che il caricamento iniziale sia riuscito:

In MongoDB Atlas, fai clic su Clusters.
Fai clic su Raccolte.
Verifica che esista un database denominato migrations e che la raccolta denominata source abbia cinque documenti.

Successivamente, verifica che le modifiche in corso ai database di origine siano riportate nei database di destinazione:

In Cloud Shell, utilizza ssh per accedere alla VM principale del set di repliche MongoDB di origine.
Avvia la shell mongo. mongo

Inserisci un altro documento:

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

Nella pagina Raccolte MongoDB Atlas per la raccolta migrazione, fai clic su Aggiorna per osservare che un documento viene aggiunto alla raccolta source.

Hai verificato che tutti i dati originali e le eventuali modifiche in corso all'origine vengano migrate automaticamente alla destinazione da Atlas Live Migration.

Test del cluster di destinazione Atlas

In un ambiente di produzione, i test sono fondamentali. È necessario testare le applicazioni che accedono ai database di destinazione per assicurarsi che funzionino correttamente. Questa sezione illustra varie strategie di test.

Testare le applicazioni con un database di destinazione durante una migrazione

Come dimostrato nella sezione precedente, puoi eseguire test delle applicazioni durante una migrazione di database in corso. Questo approccio potrebbe funzionare se le applicazioni non modificano la destinazione in modo tale da essere in conflitto con la migrazione dei dati dai database di origine. La possibilità di utilizzare questo approccio dipende dal tuo ambiente e dalle tue dipendenze. Se l'applicazione di test scrive i dati nel database di destinazione, potrebbe essere in conflitto con la migrazione in corso.

Testare le applicazioni con un database di destinazione temporaneo

Se non puoi testare le applicazioni durante una migrazione del database di produzione, puoi eseguire la migrazione dei dati a database di destinazione temporanei che utilizzi solo per il test, quindi eliminare i target di test dopo una migrazione di prova.

Per questo metodo, interrompi la migrazione di prova prima o poi (come se la migrazione del database fosse completata) e testa le applicazioni rispetto a questi database di test. Al termine del test, elimini i database di destinazione e avvia la migrazione del database di produzione per eseguire la migrazione dei dati ai database di destinazione permanenti. Il vantaggio di questa strategia è che i database di destinazione possono essere letti e scritti perché sono solo a scopo di test.

Testa le applicazioni con un database di destinazione al termine della migrazione

Se nessuna di queste due strategie è praticabile, la strategia rimanente consiste nel testare l'applicazione sul database dopo il completamento della migrazione. Una volta che tutti i dati sono presenti nei database di destinazione, testa le applicazioni prima di renderle disponibili agli utenti. Se i test includono la scrittura dei dati, è importante che questi siano scritti, non i dati di produzione, per evitare incoerenze nei dati di produzione. I dati dei test devono essere rimossi una volta completati i test per evitare incoerenze nei dati o dati superflui nel database di destinazione.

Ti consigliamo di eseguire il backup dei database di destinazione prima di aprirli per l'accesso in produzione da parte dei sistemi delle applicazioni. Questo passaggio aiuta a garantire che vi sia un punto di partenza coerente che puoi ricreare, se necessario.

Migrazione dall'origine, il set di repliche MongoDB sul cluster di destinazione

Dopo aver completato eventuali test e verificato che le modifiche in corso siano riportate nel database di destinazione, puoi pianificare il cutover.

Per prima cosa, devi arrestare eventuali modifiche al database di origine in modo che Atlas Live Migration possa scaricare le modifiche non ancora migrate al target. Dopo aver acquisito tutte le modifiche nella destinazione, puoi avviare il processo di cutover di Atlas Live Migration. Una volta completato il processo, puoi trasferire i client dall'origine ai database di destinazione.

In MongoDB Atlas, fai clic su Clusters.
Nel riquadro Cluster0, fai clic su Preparati alla migrazione. Vengono visualizzate una spiegazione passo passo del processo di cutover e una stringa di connessione al cluster di destinazione.
Fai clic su Migrazione completa.

Al termine della migrazione, viene visualizzato il messaggio Success! La migrazione del cluster è stata completata.

Hai eseguito la migrazione del tuo set di repliche MongoDB in un cluster MongoDB Atlas.

Preparare una strategia di riserva

Al termine di un cutover, il cluster di destinazione è il sistema di registrazione; i database di origine sono obsoleti e alla fine vengono rimossi. Tuttavia, ti consigliamo di utilizzare i database di origine in caso di errori gravi nei nuovi database di destinazione. Ad esempio, un errore può verificarsi se la logica di business in un'applicazione non viene eseguita durante il test e in seguito non funziona correttamente. Un altro errore si verifica quando il comportamento delle prestazioni o della latenza non corrisponde ai database di origine e causa errori.

Per evitare errori di questo tipo, puoi mantenere aggiornati i database di origine con le modifiche al database di destinazione. Atlas Live Migration non fornisce un meccanismo di riserva. Per ulteriori informazioni sulle strategie di riserva, vedi Migrazione dei database: concetti e principi (parte 2).

Esegui la pulizia

Elimina il progetto Google Cloud

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, puoi eliminare il progetto Google Cloud che hai creato per questo tutorial.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella console Google Cloud, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Metti in pausa o termina il cluster MongoDB Atlas

Per evitare ulteriori addebiti per il cluster MongoDB Atlas, devi mettere in pausa o terminare il cluster. Per maggiori informazioni sulle implicazioni della fatturazione, consulta la sezione Mettere in pausa o terminare un cluster.

Passaggi successivi

Consulta Contenuti per la migrazione dei dati di Google Cloud.
Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Centro di architettura cloud.