Migra de MongoDB a MongoDB Atlas con la migración en vivo de Atlas

Last reviewed 2023-03-01 UTC

En este instructivo se describe e implementa una migración desde un conjunto autoadministrado de réplicas de MongoDB (que contiene bases de datos) a un clúster completamente administrado en MongoDB Atlas mediante el servicio de migración en vivo de Atlas (Atlas Live Migration) de MongoDB.

El instructivo está dirigido a ingenieros, arquitectos y administradores de bases de datos que estén interesados en un servicio alojado en su totalidad en MongoDB o que sean responsables de migrar bases de datos de MongoDB en un conjunto de réplica de MongoDB a un clúster de MongoDB.

Objetivos

Configurar tu origen autoadministrado mediante la creación de documentos que se cargarán a un conjunto de réplicas de MongoDB de muestra
Configurar un clúster de destino de migración en MongoDB Atlas
Usar Atlas Live Migration para migrar una base de datos de tu conjunto de réplicas de MongoDB autoadministrada a un clúster de MongoDB Atlas completamente administrado
Comprender y seleccionar las estrategias de prueba, migración de sistemas y resguardo

En este instructivo se usa un conjunto de réplicas de MongoDB configurado como el origen. No se describe cómo migrar un clúster fragmentado de MongoDB a MongoDB Atlas. La diferencia de arquitectura entre un conjunto de réplicas de MongoDB y un clúster fragmentado de MongoDB se explica en esta publicación de Stack Exchange: Database Administrators.

A fin de completar la migración para este instructivo, usa Atlas Live Migration, no la herramienta de Atlas mongomirror. La herramienta mongomirror requiere la instalación de un agente en el entorno de origen de MongoDB y opera en un nivel de abstracción más bajo.

La configuración de migración en este instructivo es una migración homogénea con semántica de copia. Los datos no se transforman durante la migración, tampoco se consolida la base de datos ni se vuelven a fragmentar los datos. Puedes implementar una funcionalidad más allá de la semántica de copia con tecnología de integración como Striim.

La migración que se describe en este instructivo es unidireccional desde un conjunto de réplicas de origen en MongoDB hasta un clúster de MongoDB Atlas de destino. Después de que se completa la migración de sistemas desde el conjunto de réplicas de origen en MongoDB al clúster de destino, no se actualizan las bases de datos de origen con los cambios en el clúster de destino. Por lo tanto, si implementas esta solución en un entorno de producción, no podrás cambiar tus aplicaciones a bases de datos de origen actualizadas en un resguardo. Para obtener más información sobre los procesos de resguardo, consulta Migración de bases de datos: Conceptos y principios (parte 2).

Arquitectura de la migración

En el siguiente diagrama, se muestra la arquitectura de implementación que crearás en este instructivo.

Servidores de MongoDB en Compute Engine con la ruta de migración desde la instancia principal a MongoDB Atlas.

La flecha representa la ruta de migración de datos desde el conjunto de réplicas de origen de MongoDB (que se ejecuta en Compute Engine) hasta el clúster de destino en ejecución en MongoDB Atlas, en Google Cloud.

La arquitectura de implementación tiene estos componentes:

Base de datos de origen: un conjunto autoadministrado de réplicas de MongoDB que se ejecuta en tres instancias de Compute Engine
Base de datos de destino: un clúster de MongoDB Atlas completamente administrado
Servicio de migración: una configuración de Atlas Live Migration para migrar datos desde el origen hasta el destino

Aunque en este instructivo se usa un conjunto de réplicas autoadministrado de MongoDB en instancias de Compute Engine, también puedes implementar un conjunto de réplicas de origen de MongoDB en un centro de datos local o en otro entorno de nube.

Atlas Live Migration admite una estrategia de migración de bases de datos sin tiempo de inactividad. Durante la migración del conjunto de réplicas de origen de MongoDB, tus aplicaciones aún podrán acceder a las bases de datos de origen sin causar ningún impacto. Tras la carga inicial, Atlas Live Migration migra los cambios después de que comienza la migración.

Sigue estos pasos para realizar la migración de sistemas de la base de datos de origen al clúster de destino después de migrar el conjunto de datos inicial:

Suspende el acceso de escritura a la base de datos de origen.
Espera a que Atlas Live Migration recopile los cambios restantes y los aplique a la base de datos de destino.
Ejecuta la migración de sistemas en Atlas Live Migration.
Detén la base de datos de origen.

Una vez que se hayan migrado todos los datos, Atlas Live Migration te notificará sobre el progreso de la migración en la interfaz de usuario. En este punto, la migración de datos estará completa, y los sistemas de la aplicación podrán comenzar a acceder al clúster de destino como el nuevo sistema de registro.

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

Compute Engine

Para completar este instructivo, no puedes usar el nivel gratuito de MongoDB Atlas. Los tipos de máquinas disponibles en el nivel gratuito no son compatibles con Atlas Live Migration. El tipo de máquina mínimo requerido (M10 en el momento de escribir este artículo) tiene un costo de servicio por hora en MongoDB Atlas. Para generar una estimación de precios, ve a MongoDB Atlas Pricing, haz clic en Google Cloud Platform y sigue las instrucciones. Si implementas esta migración en producción, recomendamos que uses la versión alojada tradicional de MongoDB Atlas.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

Ir al selector de proyectos
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

Crea un conjunto autoadministrado de réplicas de MongoDB

Primero instala el conjunto de réplicas de MongoDB en Google Cloud. Esta base de datos funciona como tu base de datos de origen. A continuación verifica si tu base de datos de origen cumple con todas las condiciones necesarias.

Después de completar la verificación de las condiciones previas, debes habilitar la autenticación y reiniciar la instancia de origen de MongoDB. Por último, agrega un conjunto de datos de muestra a la instancia de origen de MongoDB que se migró a la base de datos de destino para probar la migración.

Instala el conjunto de réplicas de MongoDB

En Google Cloud Marketplace, ve a la instalación del conjunto de réplicas de MongoDB en Compute Engine. En el momento de la redacción de este documento, la versión actual es MongoDB 4.0.

Ir a MongoDB en Cloud Marketplace
Haz clic en Iniciar. Debido a que se habilitan varias API de Google Cloud, el proceso de inicio puede tardar un poco.

Si tienes permisos para varios proyectos, se mostrará una lista de proyectos. Selecciona el proyecto para la instalación de MongoDB.

Un conjunto de réplicas de MongoDB se implementa en un conjunto de instancias de Compute Engine según una plantilla de Deployment Manager.
Acepta todas las opciones de configuración predeterminada.
Haz clic en Implementar.
En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Usa ssh para acceder a la instancia de Compute Engine que ejecuta la instancia principal de MongoDB:
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Reemplaza los siguientes elementos:
- MONGODB_VM_NAME por el nombre de la réplica principal del conjunto de réplicas de MongoDB
- PROJECT_ID por el nombre de tu ID del proyecto de Google Cloud
- ZONE_OF_VM por la zona en la que reside la instancia de la máquina virtual (VM)
  
  Para obtener más información, consulta Geografía y regiones.
Si se genera una clave SSH, el sistema solicitará una frase de contraseña. Si no deseas proporcionar una, presiona Enter. Si proporcionas una frase de contraseña, anótala para referencia futura.

Si no puedes conectarte a través de Cloud Shell, haz clic en SSH to a servers tier VM en Deployment Manager.
Inicia el shell mongo:
```
mongo
```
Muestra la lista de las bases de datos existentes:
```
show dbs
```
El resultado es similar al siguiente:
```
admin   0.000GB
config  0.000GB
local   0.000GB
```
Mantén el shell mongo abierto para los comandos futuros.

Creaste un conjunto de réplicas de MongoDB, accediste a él y confirmaste que funciona.

Verifica las condiciones previas de la base de datos de origen

Atlas Live Migration requiere que el conjunto de réplicas de origen de MongoDB cumpla con los criterios de configuración específicos (también llamados condiciones previas). Las verificaciones se describen en la descripción general de Atlas Migration y en la documentación de Atlas. Los siguientes comandos provienen de esos recursos. Después de que verifiques las condiciones previas y realices los cambios necesarios, deberás realizar configuraciones adicionales y un reinicio en tu base de datos de origen.

Sigue estos pasos para verificar si se cumplen todas las condiciones previas:

En el shell mongo, verifica que la versión de MongoDB sea 2.6 o posterior. Para determinar la versión, abre el shell mongo en una instancia de base de datos de producción, conéctate al servidor de MongoDB mediante una conexión SSH y ejecuta el siguiente comando.
```
db.version()
```
El resultado mostrará la versión. Si tu versión es anterior a 2.6, debes seguir las instrucciones de actualización.
Verifica que tu implementación actual sea un conjunto de réplicas de MongoDB:
```
rs.status()
```
El resultado es un estado para el conjunto de réplicas de MongoDB. El siguiente resultado muestra que se inició una instancia de MongoDB sin habilitar el conjunto de réplicas de MongoDB.
```
{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}
```
En este caso, detén la instancia de MongoDB y, luego, reiníciala con el conjunto de réplicas de MongoDB habilitado. Si tienes una instancia independiente de MongoDB, actualízala a un conjunto de réplicas de MongoDB.
Accede para verificar que esté habilitada la autenticación en tu clúster de origen:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Reemplaza los siguientes elementos:
- YOUR_ADMIN_USERNAMEpor el nombre de usuario del administrador de tu implementación
La autenticación no está habilitada en el conjunto de réplicas de MongoDB que se creó anteriormente.

Si la autenticación no está habilitada, debes seguir las instrucciones para hacerlo. El siguiente es un comando de ejemplo para habilitar la autenticación, con un nombre de usuario y una contraseña de ejemplo:
```
use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "myUserAdminPassword",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase", "clusterMonitor" ]
  }
)
```
Después de habilitar la autenticación, se requiere la función clusterMonitor de MongoDB para ejecutar rs.status(). El comando anterior especifica esa función.
Comprueba que el usuario administrador tenga asignadas las funciones adecuadas para la versión del conjunto de réplicas de MongoDB. Si quieres obtener una lista de las funciones que corresponden a una versión en particular, consulta la sección sobre la seguridad del clúster de origen en la documentación de Atlas Live Migration.
```
use admin
db.getUser("YOUR_ADMIN_USERNAME")
```
El nombre de usuario debe estar entre comillas.
Opcional: Si tu implementación de MongoDB se basa en una versión anterior a la 4.2, tendrá índices con claves que superarán el límite de claves de índice de 1,024 bytes. En este caso, configura el parámetro failIndexKeyTooLong del servidor de MongoDB como false antes de iniciar el procedimiento de Atlas Live Migration.

Habilita la autenticación y reinicia el conjunto de réplicas de MongoDB

Para activar la autenticación, se requieren archivos de claves y crear un administrador. En los siguientes pasos se muestra cómo crear archivos de claves de forma manual. En un entorno de producción, recomendamos que uses secuencias de comandos para automatizar el proceso.

En Cloud Shell, crea un archivo de claves con este comando:
```
openssl rand -base64 756 > PATH_TO_KEY_FILE
```
Reemplaza los siguientes elementos:
- PATH_TO_KEY_FILE por la ubicación donde se almacena tu clave SSH (por ejemplo, /etc/mongo-key)
Habilita la autorización para cada una de las tres VM de la siguiente manera:
1. Copia el archivo de claves a la VM con este comando:
```
gcloud compute copy-files PATH_TO_KEY_FILE NAME_OF_THE_VM:PATH_TO_KEY_FILE --zone=ZONE_OF_VM
```
  Reemplaza los siguientes elementos:
  - NAME_OF_THE_VM por el nombre de una de las VM que ejecuta una réplica del conjunto de réplicas
  - ZONE_OF_VM por la zona de Google Cloud donde reside la VM a la que se hace referencia en NAME_OF_THE_VM
2. Usa ssh para acceder a la VM y cambiar el propietario y los permisos de acceso del archivo de claves:
```
sudo chown mongodb:mongodb PATH_TO_KEY_FILE

sudo chmod 400 PATH_TO_KEY_FILE
```
3. En tu editor de texto preferido, abre el archivo mongod.conf en modo de edición. Si quieres volver a escribir los cambios (posecritura), recomendamos que uses el comando sudo para iniciar el editor de texto.
4. Edita la sección security de la siguiente manera:
```
security:
  authorization: enabled
  keyFile: PATH_TO_KEY_FILE
```
5. Reinicia la réplica con este comando:
```
sudo service mongod restart
```
Verifica que puedes acceder al conjunto de réplicas principal de MongoDB de la siguiente manera:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```

Inserta datos de muestra

En los siguientes pasos, deberás insertar datos de muestra en la base de datos de origen y, luego, verificar que los documentos se hayan insertado correctamente:

En Cloud Shell, usa ssh para conectarte a la instancia principal de MongoDB en Compute Engine:
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Es posible que debas proporcionar la frase de contraseña para la clave SSH.
Inicia el shell mongo:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Proporciona la contraseña que especificaste cuando creaste el nombre de usuario del administrador.
Crea una base de datos:
```
use migration
```
Crea una colección:
```
db.createCollection("source")
```
Verifica que la colección esté vacía:
```
db.source.count()
```

Agrega los siguientes cinco documentos como el conjunto de datos inicial:

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

El resultado de cada uno de estos comandos es similar al siguiente:

WriteResult({ "nInserted" : 1 })

Verifica que agregaste correctamente los cinco documentos a la migración de la colección. El resultado debe ser 5.
```
db.source.count()
```

Una vez que se configura y se inicia la migración de la base de datos, se migrarán los documentos al clúster de destino en MongoDB Atlas.

Crea un clúster en MongoDB Atlas

En MongoDB Atlas, se denomina clúster a un conjunto de réplicas de MongoDB. Si no tienes un clúster configurado como tu base de datos de destino, sigue los pasos de esta sección. Estos pasos se basan en la documentación de MongoDB. Si ya tienes un clúster configurado como base de datos de destino, puedes omitir esta sección.

En Cloud Marketplace, ve a la página de instalación de MongoDB Atlas - Free Tier.

Ir a MongoDB Atlas en Marketplace
Haz clic en Visita el sitio de MongoDB para registrarte.
Haz clic en Launch your first cluster.
Completa la información obligatoria y haz clic en Get started free. Toma nota de la información que proporcionaste.
Haz clic en Advanced Configuration Options.
En Cloud Provider & Region, selecciona Google Cloud Platform y Iowa (us-central1).
Haz clic en la pestaña Cluster Tier y, luego, selecciona M10.
Haz clic en la pestaña Additional Settings, selecciona MongoDB 4.0 or MongoDB 4.2 y, luego, desactiva la copia de seguridad.
Haz clic en Create Cluster.

Espera hasta que se complete la creación del clúster. Ten en cuenta que el nombre del proyecto es Project 0 (con un espacio en blanco) y el nombre del clúster es Cluster0 (sin el espacio en blanco).
Nota: Se incluyen capturas de pantalla actualizadas de estos procesos en la documentación de MongoDB Atlas.

El clúster de destino está configurado y en ejecución en MongoDB Atlas.

Prueba la conmutación por error del clúster de MongoDB Atlas

Una vez que se completa la migración, el clúster en MongoDB Atlas ejecuta un reinicio progresivo. A su vez, se reinicia cada uno de los miembros del clúster. A fin de garantizar que funcione el proceso, sigue los pasos en la documentación de MongoDB para probar la conmutación por error.

Inicia la migración en vivo

Sigue estos pasos para migrar los datos de la base de datos de origen a la base de datos de destino:

Accede a MongoDBAtlas.
Ve a la página Clusters y selecciona el clúster al que deseas migrar.
En el panel del clúster de destino (Cluster 0), haz clic en el botón de puntos suspensivos .
Selecciona Migrate Data to this Cluster.
Revisa la información en la ventana que se abrirá. Cuando estés listo para realizar la migración, haz clic en I'm ready to migrate.

Aparecerá una ventana con instrucciones para la migración de datos. Las direcciones IP enumeradas deben poder acceder al conjunto de réplicas de MongoDB. Si no creaste una regla de firewall para esas direcciones, usa Cloud Shell a fin de agregar una regla de firewall basada en este comando de ejemplo:
```
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
```
En el campo Hostname:Port of the primary of your replica set, ingresa la dirección IP y el puerto de la instancia principal del conjunto de réplicas de MongoDB, como IP_ADDRESS:PORT_FOR_PRIMARY.
1. Para determinar la instancia principal, ejecuta el siguiente comando en la shell mongo en cualquier instancia que se ejecute en tu proyecto de Google Cloud:
  
  rs.isMaster().primary
2. Para buscar la dirección IP externa correspondiente, ve a la página Instancias de VM de Compute Engine. El puerto estándar de MongoDB es 27017.
Ingresa el nombre de usuario y la contraseña del administrador de tu conjunto de réplicas de MongoDB.

Deja todas las demás opciones de configuración en sus valores predeterminados.
Haz clic en Validate y, luego, realiza una de las siguientes acciones:
- Si la validación se completa correctamente, haz clic en Start Migration.
- Si la validación no se completa correctamente, sigue las instrucciones que se proporcionan para solucionar el problema. Por ejemplo, si MongoDB Atlas no puede conectarse al conjunto de réplicas de MongoDB, proporciona las direcciones IP desde las que intenta conectarse MongoDB Atlas. Para estas direcciones, agrega una regla de firewall que permita el tráfico de TCP en el puerto 27017 para los servidores del conjunto de réplicas de MongoDB.
La pantalla de MongoDB Atlas muestra el progreso. Espera hasta que veas el mensaje Initial Sync Complete! en la barra de progreso.

Se completó la carga inicial del conjunto de réplicas de MongoDB. El siguiente paso es verificar que se haya realizado correctamente.

Después de la migración inicial, MongoDB Atlas proporciona una estimación de la cantidad de horas que faltan para que realices la migración de sistemas al clúster de destino. Es posible que también recibas un correo electrónico de MongoDB con la cantidad de horas restantes, la posibilidad de extender ese tiempo y una advertencia que indica que, si no se realiza la migración de sistemas dentro del plazo determinado, se cancelará.

Verifica la migración de la base de datos

Es importante diseñar e implementar una estrategia de verificación de migraciones de bases de datos para confirmar que se haya migrado correctamente la base de datos. Si bien las estrategias de verificación dependen de tu caso de uso específico, te recomendamos que realices estas verificaciones:

Verificación de finalización. Comprueba que se haya migrado correctamente el conjunto de documentos inicial desde las bases de datos de origen (carga inicial).
Verificación dinámica. Comprueba que se estén transfiriendo los cambios en las bases de datos de origen a las bases de datos de destino (migración en curso).

Primero verifica que la carga inicial se haya realizado correctamente:

En MongoDB Atlas, haz clic en Clusters.
Haz clic en Collections.
Verifica que exista una base de datos llamada migrations y que la colección llamada source tenga cinco documentos.

A continuación verifica que los cambios en curso en las bases de datos de origen se reflejen en las bases de datos de destino:

En Cloud Shell, usa ssh para acceder a la VM principal del conjunto de réplicas de origen de MongoDB.
Inicia el shell mongo. mongo

Inserta otro documento:

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

En la página MongoDB Atlas Collections de la colección de la migración, haz clic en Refresh para ver que se agregó un documento a la colección source.

Verificaste que Atlas Live Migration migró automáticamente todos los datos de origen, además de todos los cambios en curso, al destino.

Prueba tu clúster de destino de Atlas

En un entorno de producción, las pruebas son esenciales. Es necesario probar las aplicaciones que acceden a las bases de datos de destino para garantizar que funcionen correctamente. En esta sección se analizan varias estrategias de prueba.

Prueba aplicaciones con una base de datos de destino durante una migración

Como se explicó en la sección anterior, puedes realizar pruebas de aplicaciones durante una migración de base de datos en curso. Este enfoque podría funcionar, siempre y cuando las aplicaciones no cambien el destino de manera tal que provoquen un conflicto con los datos que se están migrando desde las bases de datos de origen. Que este enfoque sea una opción dependerá del entorno y las dependencias. Si la aplicación de prueba escribe datos en la base de datos de destino, es posible que ocurran conflictos con la migración en curso.

Prueba aplicaciones con una base de datos de destino temporal

Si no puedes probar aplicaciones durante la migración de una base de datos de producción, puedes migrar los datos a bases de datos de destino temporales que solo uses para realizar pruebas. Tras la migración de prueba, podrás borrar los destinos de prueba.

Para este método, debes detener la migración de prueba en algún momento (como si se hubiera completado la migración de la base de datos) y probar las aplicaciones en las bases de datos de prueba. Una vez que se complete la prueba, podrás borrar las bases de datos de destino y comenzar la migración de la base de datos de producción para migrar los datos a las bases de datos de destino permanentes. El beneficio de esta estrategia es que se pueden leer y escribir las bases de datos de destino porque solo son para pruebas.

Prueba aplicaciones con una base de datos de destino después de completar la migración

Si ninguna de las estrategias anteriores es viable, la última alternativa es probar la aplicación en la base de datos después de que se complete la migración. Una vez que todos los datos estén en las bases de datos de destino, debes probar las aplicaciones antes de que estén disponibles para los usuarios. Si las pruebas incluyen operaciones de escritura de datos, es importante hacerlo en los datos de prueba, no en los de producción para evitar incoherencias en los datos de producción. Una vez que se completan las pruebas, se deben quitar los datos de prueba para evitar incoherencias de datos o que haya datos superfluos en la base de datos de destino.

Te recomendamos que crees una copia de seguridad de las bases de datos de destino antes de abrirlas para que los sistemas de aplicaciones de producción puedan acceder a ella. Este paso garantiza que haya un punto de partida coherente que puedas volver a crear, si fuera necesario.

Migra el sistema del conjunto de réplicas de origen de MongoDB al clúster de destino

Después de completar las pruebas y verificar que los cambios en curso se reflejen en la base de datos de destino, puedes planificar la migración de sistemas.

Primero debes detener los cambios en la base de datos de origen para que Live Atlas Migration pueda vaciar los cambios que aún no se migraron al destino. Una vez que se capturen todos los cambios en el destino, podrás iniciar el proceso de migración de sistemas de Atlas Live Migration. Una vez que se complete el proceso, podrás cambiar de cliente de la base de datos de origen a la de destino.

En MongoDB Atlas, haz clic en Clusters.
En el panel Cluster0, haz clic en Prepare to Cutover. Verás una explicación paso a paso del proceso de migración de sistemas y una string de conexión al clúster de destino.
Haz clic en Cut over.

Cuando se complete la migración, se mostrará el mensaje Success! Your cluster migration is complete..

Migraste correctamente un conjunto de réplica de MongoDB a un clúster de MongoDB Atlas.

Prepara una estrategia de resguardo

Cuando finaliza la migración de sistemas, el clúster de destino es el sistema de registro, por lo que las bases de datos de origen están desactualizadas y, en última instancia, se quitarán. Sin embargo, recomendamos que uses las bases de datos de origen en caso de que ocurran fallas graves en las nuevas bases de datos de destino. Por ejemplo, es posible que ocurra una falla si no se ejecuta la lógica empresarial de una aplicación durante la prueba y, por lo tanto, la app no funciona correctamente. Otra falla ocurre cuando el rendimiento o el comportamiento de la latencia no coinciden con las bases de datos de origen y se generan errores.

Para evitar este tipo de fallas, recomendamos que mantengas actualizadas las bases de datos originales con los cambios de las bases de datos de destino. Atlas Live Migration no proporciona un mecanismo de resguardo. Para obtener más información sobre las estrategias de resguardo, consulta Migración de bases de datos: Conceptos y principios (parte 2).

Limpia

Borra el proyecto de Google Cloud

Para evitar que se apliquen cargos a la cuenta de Google Cloud por los recursos que se usaron en este instructivo, puedes borrar el proyecto de Google Cloud que creaste para este instructivo.

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a Administrar recursos
En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Pausa o finaliza el clúster de MongoDB Atlas

Para evitar que se apliquen cargos adicionales por el clúster de MongoDB Atlas, debes pausarlo o finalizarlo. Si quieres obtener más información sobre la facturación, consulta Pause or terminate a cluster.

Próximos pasos

Consulta el contenido sobre migración de datos de Google Cloud.
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.