Importante
La función descrita en esta página no es compatible actualmente con los clústeres de Atlas Infinite durante la versión preliminar pública. Para conocer las funciones compatibles con la versión preliminar pública, consulte Disponibilidad de la versión preliminar pública.
Si Cloud Manager supervisa el clúster de origen, 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 subyacente de migración de datos, lo que permite migraciones en vivo más rápidas con menos tiempo de inactividad:
Atlas sincroniza los datos del clúster de origen al clúster de destino hasta que transfieras tus aplicaciones al set de réplicas de destino de Atlas.
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
Las limitaciones de Mongosync se aplican a esta migración en vivo.
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.
Soporte para emparejamiento de VPC y nodos privados
La siguiente tabla muestra el estado actual de soporte para el emparejamiento de VPC y nodos privados para el origen y destino de la migración en vivo a Atlas. Selecciona la pestaña para sets de réplicas o clústeres particionados.
Proveedor de nube | Emparejamiento de VPC | Nodos privados |
|---|---|---|
Azure | ||
AWS | ||
Google Cloud |
Proveedor de nube | Emparejamiento de VPC | Nodos privados |
|---|---|---|
Azure | ||
AWS | ||
Google Cloud |
Ruta de migración y plataformas compatibles
La migración en vivo de Cloud Manager a Atlas es compatible con todas las plataformas en las que se puede aprovisionar un host para Mongosync. Para obtener una lista completa de las plataformas compatibles en las que se puede aprovisionar un host para Mongosync, consulte la sección Plataformas de Mongosync.
La migración en vivo de Atlas (push) es compatible con las siguientes rutas de migración:
Clúster de origen Versión de MongoDB | Clúster de Atlas de destino Versión de MongoDB |
|---|---|
6.0.17 | 6.0.17 |
7.0.13 | 7.0.13 |
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 | Soporte para migración en vivo | notas |
|---|---|---|---|
Autónomo | Cualquier tipo de clúster | Antes de migrar un clúster de origen independiente mediante este procedimiento de migración, conviértalo en un conjunto 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 fragmentos en los clústeres de origen y destino puede variar. El clúster fragmentado de origen debe usar CSRS (Config Server Replica Sets). Para obtener más información, consulte Servidores de configuración de conjuntos de réplicas. | |
Clúster fragmentado | Set de réplicas |
Acceso requerido
Para migrar sus datos en vivo, debe tener acceso a Atlas (Project Owner y clusterMonitor).
Los usuarios con acceso Organization Owner deben añadirse al proyecto como Project Owner.
Requisitos previos
Antes de comenzar la migración en vivo desde un clúster supervisado en Cloud Manager a Atlas:
Actualiza el clúster de origen a la versión 6.0 o posterior de MongoDB.
Crea una organización de Atlas y luego crea un proyecto en esta organización.
Implementar el clúster en este proyecto.
Se debe realizar la conexión al clúster desde todos los servidores cliente donde se ejecutan las aplicaciones.
Considera configurar una conexión de emparejamiento de VPC o un nodo privado entre cada host de migración y el clúster de destino de Atlas en el mismo proveedor de nube y en la misma región que el clúster de destino.
Nota
Si decides no utilizar el emparejamiento de VPC o los nodos privados al migrar sets de réplicas, el proceso de migración en vivo se ejecuta sobre las direcciones IP públicas que agregues a la lista de acceso IP del proyecto de Atlas como parte del procedimiento de migración en vivo en esta sección.
En el clúster de origen de Cloud Manager, configure un host de migración en Cloud Manager.
El nombre de usuario y la contraseña utilizados para conectarse al clúster de origen.
Si no está utilizando un punto final privado entre el host de migración y el clúster Atlas de destino, obtenga las direcciones IP externas o los bloques CIDR de los hosts de migración aprovisionados en Cloud Manager de su administrador de Cloud Manager.
Si el clúster de origen utiliza TLS con una Autoridad de Certificación Raíz personalizada, para garantizar que los hosts puedan leer el certificado, agregue el archivo CA del clúster de origen a los hosts de migración.
Durante el proceso de migración en vivo, Atlas valida que puede recopilar estadísticas de la base de datos MongoDB mediante dbStats. Antes de migrar en vivo a un clúster deAtlas, revise la configuración del proyecto para el clúster de origen en Cloud Manager y asegúrese de que la opción Collect Database Specific Statistics esté habilitada. Esta opción está habilitada de forma predeterminada en Cloud Manager y debe permanecer habilitada para que el proceso de migración supere la validación.
Si el clúster se ejecuta con autenticación, cumpla con los siguientes requisitos previos:
Para los conjuntos de réplicas, otorgue los roles
backupyreadAnyDatabaseen la base de datos de administración al usuario que ejecutará el proceso de migración.Para clústeres fragmentados, asigne los roles
backup,readAnyDatabaseyclusterMonitoren la base de datos de administración al usuario que ejecutará el proceso de migración. Asegúrese de que el usuario especificado exista en cada fragmento y en el conjunto de réplicas del servidor de configuración. El usuario debe tener permisos que permitan 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 mediante SCRAM-SHA-1 y SCRAM-SHA-256. Para obtener más información, consulte Seguridad del clúster de origen.
Importante
Preparación del clúster de origen
Para garantizar una migración de datos sin problemas, su clúster de origen debe cumplir con todas las recomendaciones para clústeres de producción. Consulte la Lista de verificación de operaciones y las Notas de producción antes de iniciar el proceso de migración en vivo.
Nota
No puedes migrar un clúster que se encuentra en estado inactivo. El clúster que ejecuta MongoDB debe estar operativo para que la Migración en vivo a Atlas se lleve a cabo, ya que Atlas migra un nodo del clúster a la vez, comenzando por los nodos secundarios y finalizando con el nodo primario. Asegúrate de que tu clúster esté en funcionamiento antes de intentar la migración.
Flujo de trabajo de migración en vivo
Esta sección describe el flujo de trabajo. Para obtener instrucciones detalladas, consulte el procedimiento para migrar un clúster de Cloud Manager a Atlas.

Las etapas del flujo de trabajo de la migración en vivo son:
Etapa 1: Seleccione la ruta de migración en Atlas. Realice este paso en Atlas, después de haber creado su cuenta, organización y Proyecto en Atlas; implementado el clúster dedicado en este Proyecto; y se pueda conectar a él.
- Para obtener instrucciones detalladas,consulte el procedimiento para migrar un clúster de Cloud Manager a Atlas.
Etapa 2: Provisionamineto del host de migración.
Configure un host de migración en Cloud Manager. Un host de migración ejecuta un agente de MongoDB dedicado que orquesta el proceso de migración en vivo desde Cloud Manager a Atlas.
Nota
Si está migrando una implementación de origen de MongoDB que no ha utilizado Cloud Manager anteriormente, agregue los procesos de MongoDB existentes a Cloud Manager.
En la sección Live Migration: Connect to Atlas de la página Settings de su organización de Cloud Manager, seleccione Connect to Atlas y pegue el token de enlace que creó en Atlas. Para obtener más información, consulte Conectarse a Atlas para la migración en vivo en Cloud Manager.
Etapa 3: comienza la migración. En Atlas, sigue los pasos del asistente para iniciar el proceso de migración en vivo.
Dirección IP externa del host de migración en Cloud Manager
Antes de iniciar el procedimiento de migración en vivo, agregue las direcciones IP o los bloques CIDR de los hosts de migración a la lista de acceso IP del proyecto. Atlas solo permite conexiones al clúster de destino desde hosts que figuren en la lista de acceso del proyecto.
Validación previa a la migración
Antes de comenzar el procedimiento de Migración en vivo, Atlas realiza comprobaciones de validación en los clústeres de origen y destino.
La versión mínima de MongoDB del clúster de origen y destino es 6.0.17 o posterior. Las versiones no tienen que coincidir.
El usuario de la base de datos del clúster de origen tiene los permisos correctos, tal como se describe en la sección Seguridad del clúster de origen.
El clúster de destino de Atlas no tiene activado BI Connector para Atlas.
El clúster de origen permite recopilar estadísticas de la base de datos para su proyecto en Cloud Manager. Esto permite a Atlas recopilar estadísticas de la base de datos MongoDB durante el proceso de migración en vivo. Para confirmar que la opción Collect Database Specific Statistics está habilitada, revise la configuración del proyecto para el clúster de origen en Cloud Manager.
Seguridad del clúster de origen
Los diversos roles con funcionalidad incorporada proporcionan privilegios suficientes. Por ejemplo:
Para los clústeres de conjuntos de réplicas de origen, un usuario de MongoDB debe tener los roles readAnyDatabase, backup y la acción bypassWriteBlockingMode.
Para clústeres fragmentados de origen, un usuario de MongoDB debe tener los roles readAnyDatabase, backup, clusterMonitor y la acción bypassWriteBlockingMode.
El rol bypassWriteBlockingMode debe agregarse a un rol personalizado que se puede aplicar al usuario de MongoDB que se utiliza para la migración. Esto se puede agregar en clústeres Atlas o autogestionados.
Para verificar que el usuario de la base de datos que ejecutará el proceso de migración en vivo tenga estos roles, ejecute el comando db.getUser() en la base de datos admin. Por ejemplo, para un conjunto de réplicas, ejecute:
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 exigen autenticación.
Requisitos de seguridad para el host de migración
Para migraciones en vivo tipo push, eres responsable del provisionamineto, la seguridad y la ejecución del host de migración. El host de migración solo cifra la comunicación saliente con los clústeres de Atlas.
Para obtener más información sobre la seguridad de Atlas, consulte el documento técnico sobre seguridad de Atlas.
Considerations
Cifrado de la red
Durante las migraciones en vivo push, si el clúster de origen no utiliza el cifrado de TLS para tus datos, el tráfico del clúster de origen al host de migración no está cifrado, pero el tráfico del host de migración a Atlas sí está cifrado. Determina si esto es aceptable antes de iniciar un procedimiento de migración en vivo push.
Usuarios y roles de base de datos
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.
Atlas no migra ningún dato de usuario ni de rol al clúster de destino.
Si el clúster de origen ha forzado la autenticación, antes de migrar debes recrear el mecanismo de autenticación adecuado que utilizan tus aplicaciones en el clúster de Atlas de destino. La siguiente tabla enumera los mecanismos de autenticación y cómo configurarlos en Atlas.
Mecanismo de autenticación | Método de configuración |
|---|---|
SCRAM | |
LDAP | |
AWS KMS, Azure Key Vault, Google Cloud KMS |
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.
Balanceadores de clúster de origen y destino
Para evitar cualquier impacto en el rendimiento de escritura durante la migración, Atlas detiene los balanceadores de clúster fragmentados en los clústeres de origen y destino al inicio del procedimiento, y los inicia al final del mismo.
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 exitosa, un banner de advertencia indica que debe reiniciar manualmente el balanceador del clúster de origen o destino.
Configuración del clúster de destino
Para el clúster de destino, se aplican las siguientes consideraciones:
Los clústeres de origen y destino son, ambos, sets de réplicas o, ambos, clústeres fragmentados. El número de fragmentos puede diferir entre el clúster de origen y el clúster de destino.
No puedes seleccionar un Free cluster (anteriormente conocido como
M0) o un Flex cluster como el clúster de destino para migración en vivo.
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:
Dimensionamiento de oplog en la documentación de Mongosync.
Si está observando problemas de rendimiento incluso después de haber seguido estas recomendaciones, póngase en contacto con el soporte técnico.
- No cambies la bandera
featureCompatibilityVersionmientras la migración en vivo de Atlas está en ejecución.
Evite las cargas de trabajo en el clúster de destino
Evita ejecutar cualquier carga de trabajo, incluidas aquellas que puedan estar ejecutándose en un espacio de nombres que no coincida con el proceso de migración en vivo, en el clúster de destino. Esta acción evita posibles conflictos de bloqueo y la degradación del rendimiento durante el proceso de migración en vivo.
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 pausa tanto las snapshots de copias de seguridad en la nube programadas como las on-demand del clúster objetivo mientras se ejecuta la Migración en vivo. Una vez que complete el paso de transición en el procedimiento de Migración en vivo en esta página, Atlas reanudará automáticamente la toma de snapshots de copias de seguridad en la nube según su política de copias de seguridad.
Evitar cambios en el Namespace
No realice ningún cambio de espacio de nombres durante el proceso de migración, como por ejemplo usar el comando renameCollection o ejecutar una canalización de agregación que incluya la etapa de agregación $out.
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.
Entornos de producción y etapas
Considere ejecutar el siguiente procedimiento dos veces. Primero, realice una migración parcial que se detenga en el paso Perform the Cutover. Esto crea un clúster de prueba actualizado con respaldo de Atlas para evaluar el comportamiento y el rendimiento de la aplicación utilizando la última versión del controlador 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.
Migre su clúster
Importante
Evite realizar cambios en la configuración del clúster de origen mientras se ejecuta el procedimiento de migración en vivo, como eliminar miembros del conjunto de réplicas o modificar la configuración de tiempo de ejecución mongod, como featureCompatibilityVersion.
Procedimiento
En Atlas, diríjase a Migration Hub de 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.
El centro de migración muestra.
Inicie el proceso de migración.
Haga clic en Migrate from a Self-Managed MongoDB Database.
Nota
La etiqueta de la interfaz de usuario menciona Ops Manager; sin embargo, para este procedimiento, solo puedes migrar a clústeres que ejecuten MongoDB 6.0 o una versión posterior que Cloud Manager supervise.
Haga clic en I'm Ready to Start.
Atlas muestra un asistente de migración en vivo con instrucciones sobre cómo proceder con el proceso. El proceso transfiere los datos del clúster de origen al nuevo clúster de destino. Después de completar los pasos del asistente, se puede dirigir la aplicación al nuevo clúster.
Enlaza con Atlas.
Haz clic en Generate Link-Token. Atlas muestra la página para generar un link-token.
Haz clic en Next para ver una página que contiene el link-token generado.
Copia el link-token y almacénalo en una ubicación segura. Atlas nunca muestra el contenido del link-token. Atlas tampoco muestra el link-token después de generarlo. No lo compartas públicamente.
Nota
Utiliza un link-token único para migrar en vivo todos los proyectos en una sola organización de Cloud Manager a Atlas.
Haga clic en Done.
Pega el link-token en Cloud Manager.
Acceda a la organización en Cloud Manager:
Abre Cloud Manager y navega hasta la organización a la que pertenece el clúster de proyecto que estás migrando en vivo a Atlas.
Haz clic en Settings en el panel de navegación izquierdo.
En la sección Live Migration: Connect to Atlas, haz clic en Connect to Atlas. Se abre el cuadro de diálogo Connect to Atlas.
Pega el link-token que has generado en el paso anterior del asistente de Migración en vivo y haz clic en Connect to Atlas. Cloud Manager establece la conexión con Atlas. Usa el botón Refresh para enviar una actualización a Atlas, si es necesario.
Crea el clúster de Atlas de destino.
Si aún no lo ha hecho, cree un clúster de destino en Atlas.Consulte Acceso requerido.
Inicia la migración desde el clúster de destino.
Haga clic en Select Target Cluster from Projects.
Ir al proyecto del clúster de Atlas de destino y localizar el clúster de destino.
Haga clic y seleccione Migrate Data to this Cluster en la lista desplegable para iniciar la migración. Se abre la página Migrate Data to This Cluster.
Haga clic en Migrate from a Self-Managed MongoDB Database.
Nota
La etiqueta de la interfaz de usuario menciona Ops Manager; sin embargo, para este procedimiento, solo puede migrar a clústeres de Atlas que ejecuten MongoDB 6.0 o una versión posterior que Cloud Manager supervise.
Rellene los campos de la siguiente manera:
Seleccione el proyecto fuente en Cloud Manager, si no está ya seleccionado.
Selecciona el clúster de origen en el desplegable.
Si está migrando un set de réplicas a un clúster:
Si desea particionar colecciones, haga clic en la marca de verificación en Include sharding parameters y pegue la configuración JSON de particionado en el cuadro de texto utilizando el ejemplo de particionado. Guarde esta configuración en un archivo externo, en caso de que necesite consultarla más adelante.
El archivo JSON de configuración de fragmentación define el array
shardingEntries, que especifica las colecciones que se fragmentarán y las claves que se utilizarán para la fragmentación. MongoDB fragmenta únicamente las colecciones que se incluyan en este array. Para obtener más información, consulte la sección Fragmentación.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.
Selecciona un host de migración para gestionar la migración.
Si no estás utilizando un nodo privado, revisa la lista de acceso a direcciones IP y comprueba que la dirección IP externa del host de migración esté incluida en esta lista. Si no está añadido, añádelo ahora:
Haga clic Set Network Access for Host
Haga clic + Add IP Address
Regrese al asistente de migración en vivo. Selecciona el clúster de origen del menú desplegable y elige Migrate data to this cluster en .
Selecciona el clúster de origen del menú desplegable.
Si el clúster de origen aplica la autenticación, introduce un nombre de usuario y una contraseña en los cuadros de texto proporcionados.
Consulta Seguridad del clúster de origen para obtener orientación sobre los permisos de usuario necesarios para la migración en vivo de Atlas.
Si suspende el clúster de origen de la automatización en Cloud Manager, pero continúa supervisándolo con el Agente de supervisión, se mostrarán Username y Password. Si su implementación requiere autenticación de usuario, proporcione el nombre de usuario y la contraseña en estos campos. El usuario de la base de datos cuyas credenciales proporcione debe tener al menos el rol de copia de seguridad en la base de datos de administración y debe autenticarse mediante SCRAM-SHA-1 y SCRAM-SHA-256.
Si el clúster de origen utiliza TLS, active o desactive el botón Is encryption in transit enabled?.
Si el clúster de origen utiliza TLS con una Autoridad de Certificación (CA) raíz personalizada, copie la ruta al archivo de CA desde su host de migración y péguela en el cuadro de texto proporcionado. El archivo debe estar presente en el host de migración para garantizar que este pueda leer el certificado. Atlas verifica que el certificado esté presente y sea legible.
Si el clúster de destino tiene datos que se quieren preservar, se debe mantener la opción de Clear any existing data on your destination cluster desmarcada. El servicio de migración en vivo revisa una muestra de documentos durante la validación y avisa si encuentra namespaces duplicados. Si se desean borrar los datos existentes, se debe marcar esta opción y luego ingresar el nombre del clúster de destino.
Elige una conexión para conectarte al clúster. El Standard connection siempre se muestra como disponible en la interfaz de usuario. Sin embargo, otras opciones de conexión se activar solo si has configurado previamente una conexión de emparejamiento de VPC o un nodo privado para tus clústeres. Si Atlas detecta que no tienes conexiones VPC ni nodos privados configurados, estas opciones aparecen atenuadas.
Si no estás usando el emparejamiento VPC o nodos privados, haz clic en Standard connection y continúa con la etapa Validation de este paso.
Si configuró una conexión de emparejamiento de VPC entre el host de migración y el conjunto de réplicas de Atlas, la opción VPC Peering estará activa. Haga clic en VPC Peering para conectarse mediante el emparejamiento de VPC para la migración en vivo. Si la opción VPC Peering aparece atenuada, configure una conexión de emparejamiento de VPC antes de iniciar este procedimiento. Para obtener más información, consulte Compatibilidad con el emparejamiento de VPC y los puntos finales privados.
Si configuró un punto de conexión privado entre el host de migración y el clúster de Atlas, la opción Private Endpoint estará activa. Haga clic en Private Endpoint para conectarse con un punto de conexión privado y, a continuación, seleccione un punto de conexión privado configurado previamente en el menú desplegable. Solo son válidos los puntos de conexión privados que se encuentren en estado
AVAILABLE. Si la opción Private Endpoint aparece atenuada, configure un punto de conexión privado antes de iniciar este procedimiento. Para obtener más información, consulte Compatibilidad con el emparejamiento de VPC y los puntos de conexión privados.Nota
Para las migraciones en vivo push, los nodos privados son compatibles solo con los clústeres implementados en un único proveedor de nube y una sola región.
Haz clic en Validate. El proceso de validación verifica que el host de migración sea accesible y realiza las siguientes comprobaciones para garantizar que se pueda iniciar la migración en vivo a Atlas.
Para aprovechar las siguientes comprobaciones de validación, actualice el agente de MongoDB en Cloud Manager a la última versión. Las siguientes comprobaciones de validación se ejecutan durante la migración en vivo:
El host de migración puede conectarse al clúster de destino.
Si el clúster de origen utiliza TLS con una Autoridad de Certificación Raíz (CA) personalizada, el host de migración puede acceder al clúster de origen mediante TLS.
Las credenciales de usuario de base de datos son válidas. Esta comprobación de validación solo se ejecuta si suspendes el clúster de origen de la automatización en Cloud Manager, pero sigue supervisando el clúster de origen con el Agente de supervisión.
El proceso de migración verifica que el clúster de destino tenga suficiente espacio en disco según el tamaño de almacenamiento de los datos comprimidos. Para obtener más información sobre los tamaños de datos y almacenamiento, consulte dbStats.
Si la validación falla, compruebe el host de migración, la validez de sus direcciones IP externas o bloque CIDR, y el token de enlace. Compruebe también las credenciales de usuario de la base de datos, sus certificados TLS y la cantidad de espacio de almacenamiento en disco en el clúster de destino.
Si la validación tiene éxito, haz clic en Next.
Inicie la migración.
Revisa el informe que enumera la organización de origen, el proyecto y el clúster, y el host de migración que utilizará el proceso de migración en vivo.
Haga clic en Start the Migration.
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.
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.
Cuando el temporizador de retardo está casi en cero 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. Proceder 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:
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.
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.
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.
Verifique que sus 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, consulte Mongosync: Verificar la 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.
API de migración en vivo push
Para ejecutar las tareas asociadas al procedimiento de migración en vivo, consulte la API de migración en vivo mediante Push.
Nota
Las API de Migración en vivo mencionan Cloud Manager u Ops Manager; sin embargo, el tipo de migración en vivo descrito en esta sección solo admite migrar clústeres de origen supervisados en Cloud Manager a clústeres de destino en Atlas.
Comandos CLI de migración en vivo push
Para migrar un clúster usando la Atlas CLI, puede realizar los siguientes pasos:
Crear o borrar un link-token
Crear o ver una tarea de validación
Crear o ver una tarea de migración
Realizar el cambio definitivo
Para otros pasos en el procedimiento de migración en vivo, debes utilizar la interfaz de usuario de Cloud Manager o la interfaz de usuario de Atlas.
Antes de migrar un clúster usando el Atlas CLI, complete la validación previa a la migración.
Nota
Antes de ejecutar cualquier comando de Atlas CLI, debe:
Crear o borrar un link-token
Para crear un nuevo token de enlace utilizando la CLI de Atlas, ejecute el siguiente comando:
atlas liveMigrations link create [options]
Para eliminar el token de enlace que especifique mediante la CLI de Atlas, ejecute el siguiente comando:
atlas liveMigrations link delete [options]
Para obtener más información sobre la sintaxis y los parámetros de los comandos anteriores, consulte la documentación de la CLI de Atlas para atlas liveMigrations link create y atlas liveMigrations link delete.
Si está migrando desde Ops Manager, solicite una dirección IP externa e indíquela en el token de enlace. Para obtener más información, consulte la sección «Solicitar una dirección IP externa» en la documentación de Ops Manager.
Crear y ver una tarea de validación
Para crear una nueva solicitud de validación usando Atlas CLI, ejecuta el siguiente comando:
atlas liveMigrations validation create [options]
Para devolver los detalles de la solicitud de validación que especifiques usando Atlas CLI, ejecuta el siguiente comando:
atlas liveMigrations validation describe [options]
Para obtener más información sobre la sintaxis y los parámetros de los comandos anteriores, consulte la documentación de la CLI de Atlas para atlas liveMigrations validation create y atlas liveMigrations validation describe.
Para aprender qué valida Atlas, consulta el punto Validate en la sección Migrate Your Cluster de esta página.
Crear y ver una tarea de migración
Para crear una nueva tarea de migración usando el Atlas CLI, ejecuta el siguiente comando:
atlas liveMigrations create [options]
Para devolver los detalles de la tarea de migración que especifiques usando Atlas CLI, ejecuta el siguiente comando:
atlas liveMigrations describe [options]
Para obtener más información sobre la sintaxis y los parámetros de los comandos anteriores, consulte la documentación de la CLI de Atlas para atlas liveMigrations create y atlas liveMigrations describe.
Realizar el cambio definitivo
Para iniciar la transición a la migración en vivo mediante Atlas CLI, ejecuta el siguiente comando:
atlas liveMigrations cutover [options]
Para obtener más información sobre la sintaxis y los parámetros de los comandos, consulte la documentación de la CLI de Atlas para la migración en vivo de Atlas.
Cuando se complete el cambio definitivo, Atlas completará el proceso de migración en vivo y dejará de sincronizarse con el clúster de origen. Para aprender más, consulte la sección Migrate Your Cluster de esta página.
Nota
Los comandos CLI de migración en vivo pueden mencionar Cloud Manager u Ops Manager; sin embargo, el tipo de migración en vivo descrito en esta sección solo admite la migración de clústeres de origen supervisados en Cloud Manager a clústeres de destino en Atlas.
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 tiene alguna pregunta sobre el soporte de migración que no figure en esta documentación, o si encuentra un error durante la migración, solicite soporte a través de la interfaz de usuario de Atlas.
Para enviar un ticket de soporte:
Solicitud de soporte.
Haga clic en Request Support.
Para Issue Category, seleccione
Help with live migration.Para Priority, seleccione la prioridad adecuada. Para preguntas, seleccione
Medium Priority. Si hubo un fallo en la migración, seleccioneHigh Priority.Para Request Summary, incluya
Live Migrationen 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.