Esegui il deployment di Atlas Live Migration per eseguire la migrazione di MongoDB a MongoDB Atlas

Questo documento descrive come eseguire il deployment dell'architettura in Utilizzare Atlas Live Migration per eseguire la migrazione di MongoDB a MongoDB Atlas.

Questo documento è destinato agli architetti di database, agli amministratori di database e agli ingegneri di database interessati a un servizio MongoDB completamente ospitato o che sono responsabili della migrazione dei database MongoDB in una replica MongoDB impostata su un cluster MongoDB Atlas.

Architettura

Il seguente diagramma mostra l'architettura di deployment creata in questo documento:

Nel diagramma, una freccia rappresenta il percorso di migrazione dei dati dal set di repliche MongoDB di origine in esecuzione su Compute Engine al cluster di destinazione in esecuzione in MongoDB Atlas su Google Cloud. Per ulteriori informazioni sull'architettura, consulta Utilizzare Atlas Live Migration per eseguire la migrazione di MongoDB a MongoDB Atlas.

Obiettivi

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

Costi

Il deployment di questa architettura utilizza i seguenti componenti fatturabili di Google Cloud:

• Compute Engine

Per eseguire il deployment di questa architettura, non puoi utilizzare il livello gratuito di MongoDB Atlas. I tipi di macchina disponibili nel livello gratuito non supportano la migrazione Atlas Live. Il tipo di macchina minimo richiesto (M10 al momento della stesura di questo articolo) ha un costo di servizio orario in MongoDB Atlas. Per generare una stima del prezzo, vai alla pagina Prezzi di MongoDB Atlas ed esamina le informazioni sui prezzi di Google Cloud. Se implementi questa migrazione in produzione, ti consigliamo di utilizzare la versione standard ospitata di MongoDB Atlas.

Al termine del deployment, puoi evitare di continuare la fatturazione eliminando le risorse che hai creato. Per ulteriori informazioni, consulta Pulizia.

Prima di iniziare

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

   Vai al selettore progetti

2. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

Crea un set di repliche MongoDB autogestito

Per avviare il deployment, devi installare il set di repliche MongoDB su Google Cloud. Questo database funge da database di origine. Poi verificherai se il database di origine soddisfa tutte le precondizioni richieste. Questo controllo delle condizioni preliminari aiuta a prepararti per la migrazione in un ambiente di produzione. Anche se esiste già una replica MongoDB nel tuo ambiente di produzione, devi comunque verificare le precondizioni.

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 origine di cui viene eseguita la migrazione al database di destinazione.

Installa il set di repliche MongoDB

1. In Google Cloud Marketplace, vai all'installazione del set di repliche MongoDB su Compute Engine.

   Vai a MongoDB in Cloud Marketplace

2. Fai clic su Launch . Poiché sono abilitate diverse API Google Cloud, il processo di avvio 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.

   Il deployment di un set di repliche MongoDB viene eseguito su un set di istanze Compute Engine in base a un modello Deployment Manager.

3. Accetta tutte le impostazioni di configurazione predefinite.

4. Fai clic su Esegui il deployment.

5. 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.

6. Utilizza una connessione 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 progetto Google Cloud.
   • ZONE_OF_VM: la zona in cui si trova l'istanza della macchina virtuale (VM). Per ulteriori informazioni, consulta la sezione Area geografica e regioni.

   Se viene generata una chiave SSH, il sistema richiede una passphrase. Se non vuoi fornire una passphrase, premi Enter. Se fornisci una passphrase, annotala come riferimento futuro.

   Se non riesci a connetterti utilizzando Cloud Shell, fai clic su SSH per una VM di livello server in Deployment Manager.

7. Avvia la shell di mongo:

   mongo
   

8. Elenca i database esistenti:

   show dbs
   

   L'output è simile al seguente:

   admin   0.000GB
   config  0.000GB
   local   0.000GB
   

   Tieni aperta la shell di mongo per i comandi futuri.

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

Controlla le precondizioni per il database di origine

Atlas Live Migration richiede che il set di repliche MongoDB di origine soddisfi criteri di configurazione o precondizioni specifici. Anche se il set di repliche MongoDB di origine che hai installato come parte di questo deployment è conforme alla versione richiesta, devi comunque verificare le condizioni preliminari in un ambiente di produzione. I controlli delle condizioni preliminari sono descritti nella documentazione di Atlas.

Per verificare se tutte le condizioni preliminari sono soddisfatte:

1. 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 la tua versione è precedente alla 2.6, devi seguire le istruzioni per l'upgrade.

2. Verifica che il tuo deployment attuale sia un set di repliche MongoDB:

   rs.status()
   

   L'output è uno stato del set di repliche MongoDB. Il seguente output mostra che un'istanza MongoDB è stata avviata senza aver abilitato 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.

3. Verifica che l'autenticazione sia abilitata nel cluster di origine eseguendo l'accesso:

   mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
   

   Sostituisci quanto segue:

   • YOUR_ADMIN_USERNAME: il nome utente dell'amministratore del deployment.

   L'autenticazione non è abilitata per il set di repliche MongoDB creato in precedenza.

   Se l'autenticazione non è abilitata, devi seguire le istruzioni per abilitare l'autenticazione. 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, per eseguire rs.status() è necessario il ruolo di MongoDB clusterMonitor. Il comando precedente specifica questo ruolo.

4. Verifica che all'utente amministratore siano stati 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 del cluster di origine nella documentazione di Atlas Live Migration.

   use admin
   db.getUser("YOUR_ADMIN_USERNAME")
   

   Il nome utente deve essere inserito tra virgolette.

5. (Facoltativo) Se il deployment di MongoDB si basa su una versione precedente alla 4.2, contiene indici con chiavi che superano il limite di 1024 byte delle chiavi di indice. In questo caso, imposta il parametro server MongoDB failIndexKeyTooLong su false prima di avviare la procedura di migrazione live di Atlas.

Dopo aver verificato le precondizioni e apportato le modifiche necessarie, completa le configurazioni e riavvia il database, come descritto nella sezione successiva.

Abilita l'autenticazione e riavvia il set di repliche MongoDB

Per attivare l'autenticazione, devi creare dei file chiave e un amministratore. In un ambiente di produzione, puoi utilizzare gli script per automatizzare il processo.

1. In Cloud Shell, crea un file di chiave:

   openssl rand -base64 756 > PATH_TO_KEY_FILE
   

   Sostituisci quanto segue:

   • PATH_TO_KEY_FILE: la località in cui è archiviata la chiave SSH, ad esempio /etc/mongo-key.

2. 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 una connessione SSH per accedere alla VM e modificare il proprietario e le autorizzazioni di accesso del 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 richiamare le modifiche, potresti dover usare il comando sudo per avviare l'editor di testo.

   4. Modifica la sezione security del file mongod.conf:

      security:
        authorization: enabled
        keyFile: PATH_TO_KEY_FILE
      

   5. Riavvia la replica:

      sudo service mongod restart
      

3. Verifica di poter accedere all'account principale del set di repliche MongoDB:

   mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
   

Inserisci dati di esempio

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

1. In Cloud Shell, utilizza ssh per connetterti all'istanza di Compute Engine principale di MongoDB:

   gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
   

   È possibile che ti venga richiesto di fornire la passphrase per la chiave SSH.

2. Avvia la shell mongo:

   mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
   

   Fornisci la password specificata al momento della creazione del nome utente amministratore.

3. Crea un database:

   use migration
   

4. Creare una raccolta:

   db.createCollection("source")
   

5. Verifica che la raccolta sia vuota:

   db.source.count()
   

6. Aggiungi i seguenti cinque documenti 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 di ciascuno di questi comandi è simile al seguente:

   WriteResult({ "nInserted" : 1 })
   

7. Verifica di aver aggiunto correttamente i cinque documenti alla migrazione delle raccolte. Il risultato deve essere 5.

   db.source.count()
   

   Una volta configurata e avviata la migrazione del database, viene eseguita la migrazione dei documenti nel cluster di destinazione in MongoDB Atlas.

Crea 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 riportati 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.

1. In Cloud Marketplace, vai alla pagina MongoDB Atlas - Installazione del livello gratuito.

   Vai a MongoDB Atlas su Marketplace

2. Fai clic su Visita il sito di MongoDB per registrarti.

3. Fai clic su Avvia il primo cluster.

4. Inserisci le informazioni richieste e fai clic su Inizia gratuitamente. Prendi nota delle informazioni che hai fornito.

5. Fai clic su Opzioni di configurazione avanzate.

6. Per Cloud Provider e regione, seleziona Google Cloud Platform e Iowa (us-central1).

7. Fai clic sulla scheda Livello del cluster e seleziona M10.

8. Fai clic sulla scheda Impostazioni aggiuntive, seleziona MongoDB 4.0 o MongoDB 4.2 e quindi disattiva il backup.

9. 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 spazio vuoto).

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

Testare il failover del cluster MongoDB Atlas

Al termine della migrazione, il cluster in MongoDB Atlas esegue un riavvio in sequenza. Ogni membro del cluster si riavvia a turno. Per assicurarti che questo processo funzioni, testa il failover.

Avviare la migrazione live

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

1. Accedi a MongoDB Atlas.

2. Vai alla pagina Cluster, quindi seleziona il cluster in cui vuoi eseguire la migrazione.

3. Nel riquadro del cluster di destinazione (Cluster 0), fai clic su more_horiz.

4. Seleziona Esegui la migrazione dei dati in questo cluster.

5. Esamina le informazioni nella finestra visualizzata. Quando tutto è pronto per 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 basata sul seguente 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
   

6. Nel campo Nome host:Porta del principale del set di repliche, inserisci l'indirizzo IP e la porta per il set di repliche MongoDB principale, ad esempio IP_ADDRESS:PORT_FOR_PRIMARY.

   1. Per determinare l'istanza principale, esegui questo comando nella shell mongo su una delle istanze in esecuzione nel tuo progetto Google Cloud:

      rs.isMaster().primary
      

   2. Per cercare l'indirizzo IP esterno corrispondente, vai alla pagina Istanze VM di Compute Engine. La porta MongoDB standard è 27017.

7. Inserisci il nome utente e la password dell'amministratore del set di repliche MongoDB. Lascia invariati i valori predefiniti di tutte le altre impostazioni.

8. Fai clic su Convalida, quindi esegui una delle seguenti operazioni:

   • Se la convalida ha esito positivo, fai clic su Avvia migrazione.
   • Se la convalida non ha esito positivo, puoi risolvere i problemi utilizzando le istruzioni fornite. Ad esempio, se MongoDB Atlas non riesce a connettersi al set di repliche MongoDB, fornisce gli indirizzi IP da cui MongoDB Atlas sta cercando di connettersi. Per questi indirizzi, aggiungi una regola firewall che consente il traffico TCP sulla porta 27017 per i server del set di repliche MongoDB.

   La schermata di MongoDB Atlas mostra l'avanzamento della convalida. Attendi il messaggio Iniziale sincronizzazione completata! nella barra di avanzamento.

Il caricamento iniziale del set di repliche MongoDB è stato completato. Il passaggio successivo consiste nel verificare che il caricamento iniziale sia riuscito.

Una volta completata la migrazione iniziale, MongoDB Atlas fornisce una stima del numero di ore rimaste prima di eseguire il cutover al cluster di destinazione. Potresti anche ricevere un'email da MongoDB che indica il numero di ore rimaste, la possibilità di estendere questo intervallo di tempo e un avviso che indica che se non viene eseguito un aggiornamento finale entro i tempi indicati, la migrazione verrà annullata.

Verifica la migrazione del database

È importante progettare e implementare una strategia di verifica della migrazione del database per confermare che la migrazione del database abbia esito positivo. Anche se la specifica strategia di verifica dipende dal tuo caso d'uso specifico, ti consigliamo di eseguire questi controlli:

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

Innanzitutto, verifica che il caricamento iniziale sia riuscito:

1. In MongoDB Atlas, fai clic su Cluster.

2. Fai clic su Raccolte.

3. 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 riflesse nei database di destinazione:

1. In Cloud Shell, utilizza una connessione SSH per accedere alla VM principale del set di repliche MongoDB di origine.

2. Avvia la shell mongo:

   mongo
   

3. Inserisci un altro documento:

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

4. Nella pagina Raccolte di MongoDB Atlas per la raccolta della migrazione, fai clic su Aggiorna per osservare che un documento è stato aggiunto alla raccolta source.

Hai verificato che Atlas Live Migration ha eseguito automaticamente la migrazione di tutti i dati originali dall'origine e di eventuali modifiche in corso all'origine.

Testare il cluster di destinazione Atlas

In un ambiente di produzione, è importante testare le applicazioni che accedono ai database di destinazione per garantire che funzionino correttamente. Questa sezione illustra diverse strategie di test.

Testa le applicazioni con un database di destinazione durante una migrazione

Come illustrato nella sezione precedente, puoi eseguire test delle applicazioni durante la migrazione continua del database. Questo approccio potrebbe funzionare se le applicazioni non cambiano la destinazione in modo da entrare in conflitto con i dati sottoposti a migrazione dai database di origine. La possibilità di questo approccio dipende dall'ambiente e dalle dipendenze. Se l'applicazione di test scrive dati nel database di destinazione, potrebbe entrare in conflitto con la migrazione in corso.

Testa le applicazioni con un database di destinazione temporaneo

Se non riesci a testare le applicazioni durante la migrazione di un database di produzione, puoi eseguire la migrazione dei dati in database di destinazione temporanei che utilizzi solo per i test, per poi eliminare le destinazioni di test dopo una migrazione di prova.

Per questo metodo, devi interrompere la migrazione di prova a un certo punto (come se la migrazione del database sia stata completata) e quindi testare le applicazioni su questi database di test. Al termine del test, elimini i database di destinazione e avvii la migrazione del database di produzione per migrare i dati in 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 delle strategie precedenti è attuabile, la strategia rimanente consiste nel testare l'applicazione sul database al termine della migrazione. Dopo che tutti i dati si trovano nei database di destinazione, testa le applicazioni prima di renderle disponibili agli utenti. Se il test include la scrittura di dati, è importante che i dati del test siano scritti, non quelli di produzione, per evitare incoerenze nei dati di produzione. Per evitare incoerenze nei dati o dati superflui nel database di destinazione, i dati di test devono essere rimossi al termine dei test.

Ti consigliamo di eseguire il backup dei database di destinazione prima di aprirli all'accesso in produzione da parte dei sistemi delle applicazioni. Questo passaggio garantisce che esista un punto di partenza coerente che puoi ricreare, se necessario.

Esegui il migrazione dalla replica MongoDB di origine impostata al cluster di destinazione

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

Innanzitutto, devi interrompere eventuali modifiche al database di origine in modo che Atlas Live Migration possa scaricare le modifiche non ancora migrate nella destinazione. Una volta acquisite tutte le modifiche nella destinazione, puoi avviare il processo del cutover di Atlas Live Migration. Al termine del processo, puoi passare dall'origine ai database di destinazione.

1. In MongoDB Atlas, fai clic su Cluster.

2. Nel riquadro Cluster0, fai clic su Prepara la migrazione completa. Vengono visualizzate una spiegazione passo passo del processo del cutover e una stringa di connessione al cluster di destinazione.

3. Fai clic su Taglia.

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

Hai eseguito correttamente la migrazione del set di replica MongoDB su un cluster MongoDB Atlas.

Preparare una strategia di riserva

Al termine di un'operazione del cutover, il cluster di destinazione diventa il sistema di registrazione; i database di origine non sono aggiornati e alla fine vengono rimossi. Tuttavia, potrebbe essere opportuno ricorrere ai database di origine in caso di errori gravi sui nuovi database di destinazione. Ad esempio, può verificarsi un errore se la logica di business in un'applicazione non viene eseguita durante il test e in seguito non funziona correttamente. Quando il comportamento in termini di prestazioni o latenza non corrisponde ai database di origine, può verificarsi un altro errore.

Per evitare questi errori, ti conviene mantenere i database di origine originali aggiornati con le modifiche apportate al database di destinazione. Atlas Live Migration non offre un meccanismo di fallback. Per ulteriori informazioni sulle strategie di fallback, consulta Migrazione dei database: concetti e principi (parte 2).

Esegui la pulizia

Le sezioni seguenti spiegano come evitare addebiti futuri per il tuo progetto Google Cloud e le risorse MongoDB che hai utilizzato in questo deployment.

Elimina il progetto Google Cloud

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

1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. 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 ulteriori informazioni sulle implicazioni di fatturazione, consulta Mettere in pausa o terminare un cluster.

Passaggi successivi

• Consulta i contenuti sulla migrazione dei dati di Google Cloud.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.