/ /

Migrar en vivo un clúster

Docs Home

Gestión

Migrar o importar datos

Migrar en vivo un clúster

Docs Home

Gestión

Migrar o importar datos

Migrar en vivo un clúster

Migra en vivo (Pull) un clúster a Atlas

Importante

Característica no disponible en los clústeres Flex

Los clústeres flexibles no admiten esta función actualmente. Para obtener más información, consulte Limitaciones de Atlas Flex.

Atlas puede transferir un clúster de origen a un clúster de Atlas utilizando el procedimiento descrito en esta sección.

Este proceso utiliza Mongosync como herramienta de migración de datos subyacente, que permite migraciones en vivo más rápidas con menos tiempo de inactividad:

Atlas sincroniza los datos del clúster de origen al de destino hasta que migres tus aplicaciones al clúster de Atlas de destino.
Una vez que llegue al paso del corte en el siguiente procedimiento:
- Detenga el guardado en el clúster de origen.
- Detenga sus instancias de aplicación, apúntelas al clúster de Atlas y reinícielas.

Restricciones

Todas las limitaciones de Mongosync se aplican a esta migración en vivo. Para aprender más sobre estas limitaciones, consulta Limitaciones de Mongosync.

Además, la migración en vivo (pull) no brinda soporte para:

Versiones rápidas como la versión de clúster de origen o destino.
Emparejamiento de VPC o nodos privados para el clúster de origen o de destino.

La migración en vivo no admite la migración de índices de búsqueda de MongoDB desde un clúster de origen al clúster de destino.

Importante

Si planea utilizar la migración en vivo, NO elija Latest Version With Auto Upgrades Para sus clústeres dedicados. Esta opción actualiza automáticamente su clúster a la última versión secundaria. La migración en vivo solo admite versiones principales y no versiones secundarias, como la versión 8.2 de MongoDB.

Rutas de migración admitidas

La migración en vivo de Atlas descrita en esta sección admite las siguientes rutas de migración:

Source Cluster MongoDB Version	Destination Atlas Cluster MongoDB Version
5.0 Set de réplicas	7.0 Set de réplicas
5.0 Set de réplicas/clúster particionado	7.0 Clúster particionado
6.0 Set de réplicas	7.0 Set de réplicas
6.0 Set de réplicas	8.0 Set de réplicas
6.0 Set de réplicas/clúster particionado	7.0 Clúster particionado
6.0 Set de réplicas/clúster particionado	8.0 Clúster particionado
7.0 Set de réplicas	7.0 Set de réplicas
7.0 Set de réplicas	8.0 Set de réplicas
7.0 Set de réplicas/clúster particionado	7.0 Clúster particionado
7.0 Set de réplicas/clúster particionado	8.0 Clúster particionado
8.0 Set de réplicas	8.0 Set de réplicas
8.0 Set de réplicas/clúster particionado	8.0 Clúster particionado

Acceso requerido

Para migrar en vivo sus datos, debe tener Project Ownery acceso a clusterMonitor Atlas.

Los usuarios con acceso Organization Owner deben añadirse al proyecto como Project Owner.

Pares de configuración compatibles de clústeres de origen y destino

Para este tipo de migración en vivo, Atlas brinda soporte a los siguientes pares de configuración de clúster de origen y destino:

Configuración del clúster de origen	Configuración del clúster de destino	notas
Autónomo	Cualquier tipo de clúster	Antes de migrar un clúster de origen autónomo utilizando este procedimiento de migración, convierte el autónomo en un set de réplicas.
Set de réplicas	Set de réplicas
Set de réplicas	Clúster fragmentado	Cuando ejecute este tipo de migración, puede especificar los parámetros de fragmentación. Para aprender más, consulte el procedimiento de migración en vivo en esta sección y este ejemplo de fragmentación.
Clúster fragmentado	Clúster fragmentado	El número de particiones en los clústeres de origen y destino podría diferir. El clúster de origen debe usar CSRS (set de réplicas del servidor de configuración). Para obtener más información, consulte Servidores de configuración del set de réplicas.
Clúster fragmentado	Set de réplicas

Requisitos previos

Si el clúster se ejecuta con autenticación, cumpla con los siguientes requisitos previos:
- Para los sets de réplicas, otorga los roles backup, readAnyDatabase, clusterMonitor y la acción bypassWriteBlockingMode en la base de datos admin al usuario que ejecutará el proceso de migración.
  - clusterMonitor El rol no es obligatorio solo si decides desactivar la verificación integrada y la versión del clúster de origen es 6.0 o superior.
- Para los clústeres particionados, además de los roles Project Owner y clusterMonitor requeridos, concede los roles backup, readAnyDatabase y la acción bypassWriteBlockingMode en la base de datos admin al usuario que ejecutará el proceso de migración. Asegúrate de que el usuario especificado exista en cada partición y en el set de réplicas del servidor de configuración. El usuario debe tener los permisos que habiliten las siguientes acciones:
  - Detén o inicia el balanceador del clúster particionado.
  - Lee todas las bases de datos y colecciones en el host.
  - Lee el registro de operaciones en el host.
- Asegúrese de que este usuario esté autenticado usando tanto SCRAM-SHA-1 como SCRAM-SHA-256. Para aprender más, consulte Seguridad del clúster de origen.

Importante

Preparación del clúster de origen

Para ayudar a garantizar una migración de datos sin problemas, su clúster de origen debe cumplir con todas las recomendaciones de los clústeres de producción. Verifique la Lista de verificación de operaciones y las Notas de producción antes de comenzar el proceso de Migración en Vivo.

Nota

No se puede migrar un clúster inactivo. El clúster que ejecuta MongoDB debe estar operativo para que se realice la migración en vivo a Atlas, ya que Atlas migra un miembro del clúster a la vez, comenzando con los secundarios y finalizando con el principal. Asegúrese de que el clúster esté en ejecución antes de intentar la migración.

Acceso a la red

Debe configurar los permisos de red para los siguientes componentes:

El firewall del clúster de origen permite el tráfico del servidor de migración en vivo

Cualquier firewall del clúster de origen debe conceder acceso al clúster de origen al servidor de migración en vivo de MongoDB.

El proceso de migración en vivo de Atlas transmite datos a través de un servidor de migración en vivo controlado por MongoDB. Durante el proceso de migración en vivo, Atlas proporciona los rangos de IP de los servidores de migración en vivo de MongoDB. Concede el acceso de estos rangos de IP al clúster de origen. Esto permite que el servidor de migración en vivo de MongoDB se conecte a los clústeres de origen.

Nota

Si la organización tiene requisitos estrictos de red y no se puede habilitar el acceso necesario a los servidores de migración en vivo de MongoDB, se debe consultar Migrar en vivo una implementación de Community a Atlas.

El clúster de Atlas permite el tráfico desde tus servidores de aplicaciones.

Atlas permite conexiones a un clúster desde hosts agregados a la lista de acceso IP del proyecto. Agregue las direcciones IP o Bloques CIDR de los hosts de su aplicación a la lista de acceso IP del proyecto. Haga esto antes de comenzar la migración.

Atlas agrega temporalmente las direcciones IP de los servidores de migración de MongoDB a la lista de acceso IP del proyecto. Durante el proceso de migración, no puedes editar ni borrar esta entrada. Atlas remueve esta entrada una vez que se completa el procedimiento.

Para aprender cómo añadir entradas a la lista de acceso IP de Atlas, consulta Configurar entradas de la lista de acceso IP.

Validación previa a la migración

Antes de comenzar el siguiente procedimiento de migración en vivo, Atlas ejecuta verificaciones de validación en los clústeres de origen y destino y comprueba que:

El usuario de la base de datos del clúster de origen tiene los permisos correctos según se describe en Seguridad del clúster de origen.
El clúster de origen no contiene la base de datos de metadatos mongosync_reserved_for_internal_use. Debes descartar manualmente esa base de datos antes de iniciar la migración.

El clúster de destino Atlas no debe contener datos. Si el clúster tiene algún dato antes de comenzar, existe la opción de borrar los datos en el clúster de destino durante el proceso de migración en vivo. Alternativamente, se pueden borrar manualmente los datos en el clúster de destino antes de comenzar el procedimiento de migración.

Nota

Si está migrando desde un clúster de origen fragmentado que ejecuta MongoDB versión,5.0 primero debe ejecutar el siguiente cleanupOrphaned comando en el miembro principal del conjunto de réplicas de cada fragmento del clúster de origen. Este comando garantiza que todos los documentos huérfanos se purguen correctamente antes de la migración.

db.runCommand({cleanupOrphaned: "<database>.<collection>"})

Seguridad del clúster de origen

Los diversos roles con funcionalidad incorporada proporcionan privilegios suficientes. Por ejemplo:

Para los clústeres de sets de réplicas de origen, el usuario de MongoDB debe tener los roles readAnyDatabase, backup y la acción bypassWriteBlockingMode.

Para los clústeres particionados de origen, un usuario de MongoDB debe tener los roles readAnyDatabase, backup, clusterMonitor y la acción bypassWriteBlockingMode.

El bypassWriteBlockingMode debe añadirse a un rol personalizado que se puede aplicar al usuario de MongoDB que se está utilizando para la migración. Esto se puede agregar en Atlas o en clústeres autogestionados.

Para verificar que el usuario de la base de datos que ejecutará el proceso de Migración en vivo tiene estos roles, ejecuta el comando db.getUser() en la base de datos admin. Por ejemplo, para un set de réplicas, ejecuta:

use admin
db.getUser("admin")
{
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
  {
    "role" : "backup",
    "db" : "admin"
  },
  {
    "role" : "readAnyDatabase",
    "db" : "admin"
  }
  ,
  {
    "role" : "LiveMigrateWriteBlockingCustomRole",
    "db" : "admin"
  }
 ]
} ...

Especifique el nombre de usuario y la contraseña para Atlas cuando se le solicite en la pantalla de instrucciones del procedimiento de migración en vivo.

Atlas solo admite SCRAM para conectarse a clústeres de origen que aplican la autenticación.

De qué manera MongoDB asegura sus servidores de migración en vivo

En cualquier migración en vivo de tipo pull a Atlas, Atlas gestiona el servidor que ejecuta la migración en vivo y envía datos desde el origen al clúster de destino.

MongoDB toma las siguientes medidas para proteger la integridad y confidencialidad de sus datos en tránsito hacia Atlas:

MongoDB cifra los datos en tránsito entre el servidor de migración en vivo gestionado por Atlas y el clúster de destino. Si requiere cifrado para los datos en tránsito entre el clúster de origen y el servidor de migración gestionado por Atlas, configura TLS en el clúster de origen.
MongoDB protege el acceso a las instancias del servidor de migración gestionadas por Atlas de la misma manera que protege el acceso a cualquier otra parte de Atlas.
En casos raros en los que se requiere intervención para investigar y la restauración de servicios críticos, MongoDB se adhiere al principio de mínimo privilegio y autoriza solo a un pequeño grupo de usuarios privilegiados a acceder a tus clústeres de Atlas durante el tiempo mínimo necesario para reparar el problema crítico. MongoDB requiere MFA para que estos usuarios inicien sesión en los clústeres de Atlas y establezcan una conexión SSH a través del host. Conceder este tipo de acceso de usuario privilegiado requiere la aprobación de la alta gestión de MongoDB. MongoDB no permite el acceso de ningún otro personal de MongoDB a tus clústeres de MongoDB Atlas.
MongoDB permite el uso de cuentas de usuario privilegiadas únicamente para actividades privilegiadas. Para realizar actividades no privilegiadas, los usuarios privilegiados deben utilizar una cuenta separada. Las cuentas de usuario privilegiadas no pueden utilizar credenciales compartidas. Las cuentas de usuarios con privilegios deben seguir los requisitos de contraseña descritos en la sección 4.3.3 del documento técnico de Atlas Security.
Se puede restringir el acceso a los clústeres a todo el personal de MongoDB, incluidos los usuarios privilegiados, en Atlas. Si se decide restringir dicho acceso y MongoDB determina que el acceso es necesario para resolver un problema de soporte, MongoDB debe primero solicitar permiso y luego podrá decidir si restaura temporalmente el acceso de usuario privilegiado por hasta 24 horas. Se puede revocar la concesión temporal de acceso de 24 horas en cualquier momento. Activar esta restricción puede hacer que la respuesta y la resolución del problema de soporte tarde más tiempo y, como resultado, esto puede tener un impacto negativo en la disponibilidad de los clústeres de Atlas.
MongoDB revisa la autorización de acceso de usuarios privilegiados cada trimestre. Además, MongoDB revoca el acceso de un usuario privilegiado cuando ya no es necesario, incluso dentro de las 24 horas siguientes a que ese usuario privilegiado haya cambiado de rol o abandone la empresa. También registramos cualquier acceso del personal de MongoDB a tus clústeres de Atlas, conservamos los registros de auditoría durante al menos seis años e incluimos una marca de tiempo, actor, acción y resultado. MongoDB utiliza una combinación de revisiones automáticas y manuales para analizar esos registros de auditoría.

Para aprender más sobre la seguridad de Atlas, consulta el documento técnico Atlas Security. En particular, revisa la sección "Acceso del personal de MongoDB a los clústeres de MongoDB Atlas".

Considerations

Cifrado de la red

Durante las migraciones en vivo (pull), si el clúster de origen no utiliza cifrado TLS para sus datos, el tráfico desde el clúster de origen a Atlas no estará cifrado. Determina si esto es aceptable antes de iniciar un procedimiento de migración en vivo.

Usuarios y roles de base de datos

Atlas no migra ningún dato de usuario ni de rol al clúster de destino.

Si el clúster de origen no utiliza autenticación, debes crear un usuario en Atlas porque no es posible que Atlas funcione sin autenticación.

Si el clúster de origen aplica la autenticación, debes recrear las credenciales que tus aplicaciones usan en el clúster Atlas de destino. Atlas utiliza SCRAM para la autenticación de usuarios. Para obtener más información, consulta Configurar usuarios de base de datos.

Requisitos de Oplog

Requisitos del clúster de origen:

Para asegurarte de que la ventana de retardo de la Migración en vivo se mantenga dentro de los límites de la ventana de retardo de la replicación de oplog, realiza una de las siguientes acciones en el clúster de origen:
- Aumenta la mínima oplog window. Utiliza esta opción si el escalado automático de almacenamiento está habilitado (esto es por defecto) en el clúster de origen.
- Aumenta el tamaño fijo del oplog. Utiliza esta opción si desactivas el escalado automático de almacenamiento en el clúster de origen.

Requisitos del clúster de destino:

Para poder adaptarse a posibles fluctuaciones de tamaño del almacenamiento relacionadas con los requisitos de tamaño de oplog, recomendamos elegir un nivel de clúster de destino que esté al menos dos niveles por encima del clúster de origen.
La migración en vivo realiza la verificación integrada por defecto, lo que requiere que el clúster de destino tenga un tamaño de oplog grande. Esto previene los errores del proceso de verificación debido a un tamaño limitado del oplog.
- Si el escalado automático del almacenamiento está deshabilitado en el clúster de destino, aumenta el tamaño del oplog en el clúster de destino a un valor fijo lo suficientemente alto.
- Si escalado automático del almacenamiento está habilitado en el clúster de destino, establece una oplog window mínima suficientemente alta en el clúster de destino.
Si no puedes asignar un tamaño de oplog lo suficientemente grande o aumentar un oplog window en el clúster de destino, desactiva el interruptor Verify data post-migration (recommended) en la interfaz de usuario de migración en vivo y utiliza uno de los métodos de verificación de migración en vivo descritos en Mongosync: Verificar la transferencia de datos.

Balanceadores de clúster de origen y destino

Para evitar cualquier impacto en el rendimiento de guardado durante la migración, Atlas detiene los balanceadores de clúster particionado en los clústeres de origen y destino al inicio del procedimiento, y los inicia al final del procedimiento.

Si cancela la migración en vivo, Atlas reinicia los balanceadores en los clústeres de origen y destino.

Si Atlas no puede reiniciar el balanceador de carga en los clústeres de origen o destino al finalizar una migración en vivo con éxito, aparecerá un banner de advertencia que indicará que se debe reiniciar manualmente el balanceador de carga del clúster de origen o destino.

Configuración del clúster de destino

Cuando configure el clúster de destino, considere lo siguiente:

El clúster de destino Atlas no debe contener datos. Si el clúster tiene algún dato antes de comenzar, existe la opción de borrar los datos en el clúster de destino durante el proceso de migración en vivo. Alternativamente, se pueden borrar manualmente los datos en el clúster de destino antes de comenzar el procedimiento de migración.

El proceso de migración en vivo transmite datos a través de un servidor de migración en vivo gestionado por MongoDB. Cada servidor se ejecuta en una infraestructura alojada en la región más cercana al clúster de origen. Están disponibles las siguientes regiones:
Europa
- Fráncfort
- Irlanda
- London
Americas
- Este de EE. UU.
- Oeste de EE. UU.
APAC
- Mumbai
- Singapur
- Sídney
- Tokyo
Se debe usar la región de nube para el clúster de destino en Atlas que tenga la latencia de red más baja en relación con los servidores de aplicaciones o con la implementación alojada en el clúster de origen. Idealmente, los servidores de la aplicación deberían estar ejecutándose en la nube en la misma región que la región primaria del clúster Atlas de destino. Para obtener más información, se debe consultar Proveedores de nube.

El clúster de destino en Atlas debe igualar o superar la implementación de origen en términos de RAM, CPU y almacenamiento. Aprovisiona un clúster de destino de un tamaño adecuado para que pueda adaptar tanto el proceso de migración como la carga de trabajo prevista, o escala el clúster de destino a un nivel con más potencia de procesamiento, ancho de banda o E/S de disco.
Para maximizar el rendimiento de la migración, utiliza al menos un clúster M40 para el clúster de destino. Al migrar grandes conjuntos de datos, utiliza un clúster M80 con discos con 6000 IOPS o superiores.
También puede optar por aumentar temporalmente el tamaño del clúster de Atlas de destino durante el proceso de migración.
Después de migrar la carga de trabajo de la aplicación a un clúster en Atlas, se puede contactar al soporte para recibir ayuda al ajustar el rendimiento y dimensionar el clúster de destino para minimizar los costos.
Para evitar cambios de tamaño inesperados, desactiva el escalado automático en el clúster de destino. Para obtener más información, consulta Gestión de clústeres.
Para evitar el crecimiento ilimitado de la colección de oplog y garantizar que la ventana de retraso de la migración en vivo se mantenga dentro de los límites de la ventana de atraso de la replicación del oplog, establece un tamaño de oplog en un valor fijo lo suficientemente grande durante el proceso de migración en vivo.
Para obtener más información, consulta:
Si está observando problemas de rendimiento incluso después de haber seguido estas recomendaciones, póngase en contacto con el soporte técnico.

No puede seleccionar un M0 (nivel gratuito) o un clúster Flex como el clúster de destino para la Migración en vivo.
No cambie la bandera featureCompatibilityVersion mientras la migración en vivo de Atlas esté en ejecución.

Evite las cargas de trabajo en el clúster de destino

Las escrituras están bloqueadas durante la migración en vivo:

Cuando se inicia una migración en vivo, se bloquea el guardado en el clúster de destino. Los intentos de realizar guardados en el clúster de destino fallan.
Antes de proceder con el cambio, se debe detener manualmente la escritura en el clúster de origen. Atlas aplica esto activando el bloqueo de escritura en el clúster de origen durante el proceso de corte.
Importante
Durante el corte definitivo, el bloqueo de guardado en los clústeres de origen y destino se produce si estás migrando un clúster de origen que ejecuta la versión 6.0 de MongoDB y posteriores.
Después de que una migración en vivo se complete con éxito o falle, las operaciones de guardado en el clúster de destino pueden continuar.
Nota
Cuando se completa la migración, Atlas intenta automáticamente remover los bloques de guardado.
Si se necesita remover manualmente el bloqueo de guardado en el clúster, se debe usar el comando setUserWriteBlockMode con el campo global configurado en false:
db.adminCommand( { setUserWriteBlockMode: 1, global: false } )
Para ejecutar el comando setUserWriteBlockMode, el usuario debe tener el privilegio setUserWriteBlockMode.

No ejecutes múltiples migraciones al mismo clúster de destino simultáneamente.

No inicies el proceso de cambio de tus aplicaciones al clúster de destino mientras el proceso de migración se en vivo esté sincronizando.

Evite las copias de seguridad en la nube

Atlas deja de tomar snapshots de copias de seguridad en la nube on-demand del clúster objetivo durante la migración en vivo. Una vez que se complete el paso de transición en el procedimiento de migración en vivo en esta página, Atlas reanudará la toma de snapshots de copias de seguridad en la nube basadas en la política de copias de seguridad.

Evita las elecciones

El proceso de migración en vivo realiza el mejor esfuerzo para continuar la migración durante las interrupciones temporales de la red y las elecciones en los clústeres de origen o destino. Sin embargo, estos eventos podrían causar que el proceso de migración en vivo falle. Si el proceso de migración en vivo no puede recuperarse automáticamente, reinícielo desde el principio.

Migre su clúster

Nota

Migraciones de producción y etapas

Considera ejecutar este procedimiento dos veces. Ejecuta una migración parcial que se detenga en el paso Perform the Cutover primero. Esto crea un clúster de ensayo actualizado respaldado por Atlas para probar el comportamiento y el rendimiento de la aplicación utilizando la última versión del controlador que es compatible con la versión de MongoDB del clúster de Atlas.

Después de probar la aplicación, ejecuta el procedimiento completo de migración utilizando un clúster de Atlas aparte para crear el entorno de producción respaldado por Atlas.

Lista de verificación previa a la migración

Antes de comenzar el procedimiento de migración en vivo:

Si aún no tiene un clúster de destino, cree una nueva implementación de Atlas y configúrela según sea necesario. Para obtener la documentación completa sobre cómo crear un clúster de Atlas, consulte Crear un clúster.
Después de implementar el clúster de Atlas, se debe garantizar la posibilidad de conexión a partir del hardware cliente donde se ejecutan las aplicaciones. Probar la cadena de conexión ayuda a asegurar que el proceso de migración de datos se pueda completar en un tiempo de inactividad mínimo.
1. Descarga e instala mongosh en una máquina del cliente representante, si aún no lo tiene.
2. Conéctese a su clúster de destino usando la cadena de conexión de la interfaz de usuario de Atlas. Para obtener más información, consulte Conéctese a un clúster a través de mongosh.
Una vez que se haya verificado la conectividad con el clúster de destino, se debe iniciar el procedimiento de migración en vivo.

Procedimiento

En Atlas, vaya a Migration Hub para su proyecto.

Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.
Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Migration en la sección Services.

Se muestra el Centro de migración.

Haga clic en Migrate from Atlas para iniciar el proceso de migración.

Atlas muestra una pantalla de instrucciones paso a paso sobre cómo proceder con la migración en vivo. El proceso sincroniza los datos del clúster de origen con el nuevo clúster de destino. Después de completar el recorrido, se puede dirigir la aplicación al nuevo clúster.

Haga clic en Get Started para configurar los detalles de la migración.

Se muestra la pantalla Migration from Atlas to Atlas .

Configure sus ajustes de migración en vivo en la pantalla Set up Migration.

Conéctese a su clúster de origen.
1. Seleccione el origen Organization en el menú desplegable.
2. Después de eso, seleccione el origen Project en el menú desplegable.
3. Por último, seleccione el origenCluster en el menú desplegable.
Conecte su clúster de destino.
Nota
Solo puede seleccionar un clúster de destino que pertenezca a la organización desde la cual inicia la migración. Para iniciar el proceso de migración, asegúrese de estar en la misma organización que el clúster de destino.
1. Seleccione el destino Project en el menú desplegable.
2. Seleccione el destino Cluster en el menú desplegable.
  El clúster de destino debe ser un clúster de Atlas nuevo o vacío. Si el clúster de destino tiene datos existentes, puede optar por borrar estos datos durante el proceso de migración. Si deja esta opción desmarcada y el clúster de destino tiene datos durante el proceso de migración, la migración fallará y emitirá un error de validación.
Configure ajustes adicionales.
- Atlas muestra una casilla de verificación para Verify data post-migration (recommended). Si marca esta opción, Atlas verificará automáticamente los datos compatibles después de la migración. Si deja esta opción sin marcar, deberá ejecutar manualmente la verificación completa de los datos. Para obtener más información, consulte Verificar migraciones.
- Si su clúster de destino tiene datos existentes y marca la opción Clear any existing data on your destination cluster?, Atlas borra los datos existentes. Si deja esta opción sin marcar y el clúster de destino tiene datos con namespaces en conflicto durante el proceso de migración, fallará la migración y se emitirá un error de validación.
- Si está migrando un set de réplicas a un clúster:
  - Si se desea particionar colecciones, se debe hacer clic en la marca de verificación en Include sharding parameters y se debe pegar la configuración JSON de particionado en el cuadro de texto usando el ejemplo de particionado. Se debe guardar esta configuración en un archivo externo, en caso de que se desee consultarla más adelante.
    La configuración de particionado JSON define el arreglo shardingEntries, que especifica las colecciones a particionar y las claves que se usarán para el particionado. MongoDB particiona únicamente las colecciones que incluyas en este arreglo. Para aprender más, consulta Particionado.
    Si omites especificar la configuración de particionado, podrás particionar las colecciones en el clúster de destino después de migrar el clúster a Atlas.
  - Además de la configuración de particionado, debe existir un índice compatible para las claves de particionado especificadas en el clúster de destino que esté en servicio.
    Haz clic en la marca de verificación en Create supporting indexes para que MongoDB cree automáticamente los índices de soporte de clave de partición en el clúster de destino en Atlas.

Haga clic en Continue para validar sus datos.

El botón Continue cambia a Validating... cuando Atlas valida la información que ha proporcionado.
Si la validación falla, verifique que:
- Se ha agregado Atlas a la lista de acceso IP en el clúster de origen.
- Las credenciales de usuario proporcionadas, si las hay, están en el clúster de origen y tienen los permisos necesarios.
- El archivo CA proporcionado, si existe, es válido y correcto.
- Consulte Seguridad del Clúster de Origen para obtener orientación sobre los permisos de usuario necesarios para la migración en vivo de Atlas.
Una vez que se complete la validación, haga clic en Continue nuevamente.

Revise la información que proporcionó en la pantalla Review & Confirm.

Si necesita cambiar alguna información, haga clic en Back para volver al paso anterior y realizar cambios.

Haga clic en Start Migration.
Aparece un modal para confirmar que desea iniciar la migración.

Haga clic en Start Migration en el modal para iniciar el proceso de migración.

Una vez que comience el proceso de migración, la interfaz de usuario de Atlas muestra la pantalla del recorrido Migrating Data para el clúster de Atlas de destino. La pantalla de guía se actualiza a medida que el clúster de destino avanza en el proceso de migración. El proceso de migración incluye:

Aplicar nuevas escrituras a los datos del clúster de origen en los datos del clúster de destino.
Copiar los datos del clúster de origen al clúster de destino.
Cómo finalizar la migración en el clúster de destino.
Cómo ejecutar el proceso de verificación, si se ha activado. Si se inició la migración con la configuración de Verify data post-migration (recommended) activada, Atlas notificará que se ha realizado la verificación de datos para los tipos compatibles. Si se inició la migración con la verificación sin activar, en su lugar Atlas pedirá que se verifiquen los datos manualmente. Para obtener más información, se debe consultar Verificar las migraciones.

Durante la fase final del proceso de migración, se muestra un valor de tiempo de retardo que representa el retraso actual entre los clústeres de origen y destino.

Recibes una notificación por correo electrónico cuando la ventana de caducidad está a punto de expirar.

Cuando el retraso respecto a la fuente es casi nulo y se ha completado el proceso de migración, Atlas activa el botón Cutover to your destination cluster e indicará que los clústeres de origen y destino están sincronizados. Procede al siguiente paso.

Realiza el cambio definitivo.

El cambio definitivo es un proceso de tres pasos que dirige las lecturas y las escrituras de la aplicación fuera del clúster de origen hacia el clúster de destino.

Cuando Atlas detecta que los clústeres de origen y destino están casi sincronizados, inicia un temporizador extensible de 120 horas (5 días) para comenzar la etapa de corte del procedimiento de migración en vivo. Después de que pase el período de 120 horas, Atlas deja de sincronizarse con el clúster de origen.

En esta etapa del proceso de migración, puedes proceder al cambio definitivo o ampliar el periodo de sincronización y luego proceder al cambio.

Si haces clic en I'm ready to cutover, Atlas inicia el proceso de cambio definitivo.

Si haces clic Extend Sync, y si la sincronización extendida se completa correctamente, Atlas confirma que los clústeres de origen y destino están sincronizados. Continúa con el proceso de cambio. Si el tiempo de sincronización expira, puedes volver a intentar la migración.

Si su migración está a punto de expirar, Atlas le envía un email similar al siguiente ejemplo:

A migration to your Atlas cluster will expire in <number> hours!
Navigate to your destination cluster to start the cutover process. If
you don't take any action within <number> hours, the migration will be
cancelled and you will need to start again. You can also extend the
migration process if you need more time.

Se debe hacer clic en I'm ready to cutover. Se debe proceder rápidamente con el proceso de cambio definitivo en tres pasos para asegurar un tiempo de inactividad mínimo para la aplicación.
Haz clic en Proceed to cutover. El proceso de cambio definitivo en tres pasos comienza:
1. Se deben detener las escrituras en el clúster de origen. Se debe hacer clic en I confirm that I've stopped writes to my source cluster. Se debe hacer clic en Finalize migration para continuar.
2. Espera unos minutos mientras Atlas finaliza la migración. Atlas realiza estas acciones para completar el proceso:
  - Elimina las subredes del servidor de migración en vivo de MongoDB de la lista de acceso IP en el clúster de destino.
  - Remueve el usuario de base de datos que utilizó la migración en vivo para importar datos al clúster de destino.
  Si el proceso de transición ha estado en curso durante al menos 12 horas, Atlas le envía un email sugiriéndole que verifique el proceso de migración o que se ponga en contacto con el soporte técnico.
3. Si la migración tiene éxito, se muestra la página You have successfully migrated to Atlas. Atlas muestra el estado de los cambios sincronizados, el tiempo de inactividad de la aplicación, la duración del proceso de migración, la cantidad de datos iniciales copiados y el número de colecciones copiadas.
  - Verifica que tus datos se transfieran al clúster de destino comparando el número de documentos y realizando comparaciones de hash. Para obtener más información, consulta Mongosync: Verificar transferencia de datos.
  - Se debe hacer clic en Connect to your new cluster. Atlas redirecciona a la página Connect to Atlas, donde se puede elegir un método de conexión.
  - Después de la conexión al clúster, se debe reanudar la escritura en el clúster de destino.

En Atlas, vaya a Migration Hub para su proyecto.

Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.
Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Migration en la sección Services.

Se muestra el Centro de migración.

Haga clic en Migrate from Self-Managed para iniciar el proceso de migración.

Haga clic en Get Started para configurar los detalles de la migración.

Se muestra la pantalla Migrate from Self-Managed MongoDB Database to Atlas .

Configure sus ajustes de migración en vivo en la pantalla Set up Migration.

Introduzca su Connection String de MongoDB para conectarse al clúster de origen.

Nota

La migración en vivo no admite la cadena de conexión en el formato de conexión SRV. La validación de la migración en vivo solo acepta el formato estándar de cadena de conexión.

La cadena de conexión incluye el nombre de usuario y la contraseña de autenticación de la base de datos utilizados para conectarse al clúster de origen. Para los sets de réplicas, el usuario de la base de datos debe tener los roles readAnyDatabase, backup y la acción bypassWriteBlockingMode. Para los clústeres particionados, el usuario de la base de datos debe tener los roles readAnyDatabase, backup, clusterMonitor y la acción bypassWriteBlockingMode.

Un clúster de set de réplicas cadena de conexión estándar para un nombre de clúster replica y que incluye tres instancias de mongod, se ve como en el siguiente ejemplo:

mongodb://<db_username>:<db_password>@replica-shard-00-00.AA000.example.net:27017,replica-shard-00-01.AA000.example.net:27017,replica-shard-00-02.AA000.example.net:27017/?tls=true&replicaSet=atlas-example-shard-0&authSource=admin&appName=replica

Nota

Si no puede exponer públicamente todos los miembros del conjunto de réplicas, puede añadir el directConnection=true parámetro a su cadena de conexión para conectarse solo a través del nodo principal. Tenga en cuenta que el parámetro de la opción directConnection distingue entre mayúsculas y minúsculas.

Al utilizar directConnection=true, la migración implica un riesgo adicional de falla si el nodo principal deja de estar disponible en cualquier momento durante el proceso de migración.

Un clúster particionado cadena de conexión estándar para un nombre de clúster sharded y con una configuración de dos particiones, se ve como el siguiente ejemplo:

mongodb://<db_username>:<db_password>@sharded-config-00-00.AA000.example.net:27016,sharded-config-00-01.AA000.example.net:27016,sharded-config-00-02.AA000.example.net:27016,sharded-shard-00-00.AA000.example.net:27016,sharded-shard-00-01.AA000.example.net:27016,sharded-shard-00-02.AA000.example.net:27016/?tls=true&authSource=admin&appName=sharded

Si el clúster de origen utiliza TLS/SSL y no está utilizando una Autoridad de Certificación (CA) pública, necesitará el archivo CA del clúster de origen.

Conecte su clúster de destino.
1. Seleccione el destino Project en el menú desplegable.
2. Seleccione el destino Cluster en el menú desplegable.
  El clúster de destino debe ser un clúster de Atlas nuevo o vacío. Si el clúster de destino tiene datos existentes, puede optar por borrar estos datos durante el proceso de migración. Si deja esta opción desmarcada y el clúster de destino tiene datos durante el proceso de migración, la migración fallará y emitirá un error de validación.
Permita direcciones IP.
Si su clúster de origen tiene habilitada la lista de acceso IP, agregue las direcciones IP del servidor de migración en vivo de MongoDB a la lista de acceso IP del clúster de origen. Puede encontrar las direcciones IP en la pantalla de recorrido.
Agregue solo las direcciones IP específicas de la interfaz de usuario a su lista de acceso. No configure su clúster de origen para permitir el acceso desde cualquier lugar (0.0.0.0/0), ya que esto lo expone a todo internet.
Si su clúster de origen no tiene activada la lista de acceso IP, puede omitir este paso.
Configure ajustes adicionales.
- Atlas muestra una casilla de verificación para Verify data post-migration (recommended). Si marca esta opción, Atlas verificará automáticamente los datos compatibles después de la migración. Si deja esta opción sin marcar, deberá ejecutar manualmente la verificación completa de los datos. Para obtener más información, consulte Verificar migraciones.
- Si su clúster de destino tiene datos existentes y marca la opción Clear any existing data on your destination cluster?, Atlas borra los datos existentes. Si deja esta opción sin marcar y el clúster de destino tiene datos con namespaces en conflicto durante el proceso de migración, fallará la migración y se emitirá un error de validación.
- Si está migrando un set de réplicas a un clúster:
  - Si se desea particionar colecciones, se debe hacer clic en la marca de verificación en Include sharding parameters y se debe pegar la configuración JSON de particionado en el cuadro de texto usando el ejemplo de particionado. Se debe guardar esta configuración en un archivo externo, en caso de que se desee consultarla más adelante.
    La configuración de particionado JSON define el arreglo shardingEntries, que especifica las colecciones a particionar y las claves que se usarán para el particionado. MongoDB particiona únicamente las colecciones que incluyas en este arreglo. Para aprender más, consulta Particionado.
    Si omites especificar la configuración de particionado, podrás particionar las colecciones en el clúster de destino después de migrar el clúster a Atlas.
  - Además de la configuración de particionado, debe existir un índice compatible para las claves de particionado especificadas en el clúster de destino que esté en servicio.
    Haz clic en la marca de verificación en Create supporting indexes para que MongoDB cree automáticamente los índices de soporte de clave de partición en el clúster de destino en Atlas.

Haga clic en Continue para validar sus datos.

El botón Continue cambia a Validating... cuando Atlas valida la información que ha proporcionado.
Si la validación falla, verifique que:
- Se ha agregado Atlas a la lista de acceso IP en el clúster de origen.
- Las credenciales de usuario proporcionadas, si las hay, están en el clúster de origen y tienen los permisos necesarios.
- El archivo CA proporcionado, si existe, es válido y correcto.
- Atlas muestra la dirección IP del servidor de migración en vivo de MongoDB que es responsable de la migración en vivo en la parte superior de la pantalla de guía. Se debe configurar el firewall del clúster de origen para permitir el acceso a la dirección IP que se muestra.
- Consulte Seguridad del Clúster de Origen para obtener orientación sobre los permisos de usuario necesarios para la migración en vivo de Atlas.
Una vez que se complete la validación, haga clic en Continue nuevamente.

Revise la información que proporcionó en la pantalla Review & Confirm.

Si necesita cambiar alguna información, haga clic en Back para volver al paso anterior y realizar cambios.

Haga clic en Start Migration.
Aparece un modal para confirmar que desea iniciar la migración.

Haga clic en Start Migration en el modal para iniciar el proceso de migración.

Aplicar nuevas escrituras a los datos del clúster de origen en los datos del clúster de destino.
Copiar los datos del clúster de origen al clúster de destino.
Cómo finalizar la migración en el clúster de destino.
Cómo ejecutar el proceso de verificación, si se ha activado. Si se inició la migración con la configuración de Verify data post-migration (recommended) activada, Atlas notificará que se ha realizado la verificación de datos para los tipos compatibles. Si se inició la migración con la verificación sin activar, en su lugar Atlas pedirá que se verifiquen los datos manualmente. Para obtener más información, se debe consultar Verificar las migraciones.

Durante la fase final del proceso de migración, se muestra un valor de tiempo de retardo que representa el retraso actual entre los clústeres de origen y destino.

Recibes una notificación por correo electrónico cuando la ventana de caducidad está a punto de expirar.

Realiza el cambio definitivo.

El cambio definitivo es un proceso de tres pasos que dirige las lecturas y las escrituras de la aplicación fuera del clúster de origen hacia el clúster de destino.

En esta etapa del proceso de migración, puedes proceder al cambio definitivo o ampliar el periodo de sincronización y luego proceder al cambio.

Si haces clic en I'm ready to cutover, Atlas inicia el proceso de cambio definitivo.

Si su migración está a punto de expirar, Atlas le envía un email similar al siguiente ejemplo:

A migration to your Atlas cluster will expire in <number> hours!
Navigate to your destination cluster to start the cutover process. If
you don't take any action within <number> hours, the migration will be
cancelled and you will need to start again. You can also extend the
migration process if you need more time.

Se debe hacer clic en I'm ready to cutover. Se debe proceder rápidamente con el proceso de cambio definitivo en tres pasos para asegurar un tiempo de inactividad mínimo para la aplicación.
Haz clic en Proceed to cutover. El proceso de cambio definitivo en tres pasos comienza:
1. Se deben detener las escrituras en el clúster de origen. Se debe hacer clic en I confirm that I've stopped writes to my source cluster. Se debe hacer clic en Finalize migration para continuar.
2. Espera unos minutos mientras Atlas finaliza la migración. Atlas realiza estas acciones para completar el proceso:
  - Elimina las subredes del servidor de migración en vivo de MongoDB de la lista de acceso IP en el clúster de destino.
  - Remueve el usuario de base de datos que utilizó la migración en vivo para importar datos al clúster de destino.
  Si el proceso de transición ha estado en curso durante al menos 12 horas, Atlas le envía un email sugiriéndole que verifique el proceso de migración o que se ponga en contacto con el soporte técnico.
3. Si la migración tiene éxito, se muestra la página You have successfully migrated to Atlas. Atlas muestra el estado de los cambios sincronizados, el tiempo de inactividad de la aplicación, la duración del proceso de migración, la cantidad de datos iniciales copiados y el número de colecciones copiadas.
  - Verifica que tus datos se transfieran al clúster de destino comparando el número de documentos y realizando comparaciones de hash. Para obtener más información, consulta Mongosync: Verificar transferencia de datos.
  - Se debe hacer clic en Connect to your new cluster. Atlas redirecciona a la página Connect to Atlas, donde se puede elegir un método de conexión.
  - Después de la conexión al clúster, se debe reanudar la escritura en el clúster de destino.

Soporte para la migración

Si su migración falla en cualquier etapa del proceso de migración en vivo, Atlas le enviará por email un enlace para explorar los resultados de la migración.

Si tienes alguna pregunta sobre el soporte de migración que no figure en estos documentos, o si encuentras un error durante la migración, solicita soporte a través de la interfaz de usuario de Atlas.

Para enviar un ticket de soporte:

En Atlas, diríjase a la página Support.

Si aún no se muestra, selecciona la organización deseada en el menú Organizations de la barra de navegación.
Haga clic en el icono Support en la barra de navegación.
Haga clic en View plan.

Aparece la página de soporte.

Solicitud de soporte.

Haga clic en Request Support.
Para Issue Category, seleccione Help with live migration.
Para Priority, selecciona la prioridad adecuada. Si tienes preguntas, selecciona Medium Priority. Si hubo un fallo en la migración, selecciona High Priority.
Para Request Summary, por favor incluya Live Migration en su resumen.
Para More details, incluye cualquier otro detalle relevante sobre la pregunta o el error de migración.
Haz clic en el botón Request Support para enviar el formulario.

Volver

Migrar en vivo un clúster

Publica desde Cloud Manager