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 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 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.
Live migration doesn't support migrating MongoDB Search indexes from a source cluster to the destination cluster.
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 puedas aprovisionar un host para Mongosync. Para ver una lista completa de plataformas compatibles en las que puedes aprovisionar un host para Mongosync, consulta plataformas de Mongosync.
La migración en vivo de Atlas (push) es compatible con las siguientes rutas de migración:
Source Cluster MongoDB Version | Destination Atlas Cluster MongoDB Version |
|---|---|
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 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 |
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.
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 en Cloud Manager, se debe aprovisionar 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 se está utilizando nodos privados entre el host de migración y el clúster de destino de Atlas, se deben obtener las direcciones IP externas o los bloques CIDR de los hosts de migración aprovisionados en Cloud Manager del administrador de Cloud Manager.
Si el clúster de origen utiliza TLS/SSL con una Autoridad de Certificación Raíz (CA) personalizada, para asegurarte de que los hosts puedan leer el certificado, añade el archivo CA del clúster de origen a los hosts de migración.
During the live migration process, Atlas validates that it can collect MongoDB database statistics using dbStats. Before you live migrate to an Atlas cluster, review the project settings for the source cluster in Cloud Manager and ensure that the option Collect Database Specific Statistics is enabled. This option is enabled by default in Cloud Manager, and it should remain enabled so that the migration process passes validation.
Si el clúster se ejecuta con autenticación, cumpla con los siguientes requisitos previos:
Para los sets de réplicas, concede los roles de
backupyreadAnyDatabaseen la base de datos admin al usuario que ejecutará el proceso de migración.Para los clústeres particionados, concede los roles
backup,readAnyDatabaseyclusterMonitoren 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.
Flujo de trabajo de migración en vivo
Esta sección describe el flujo de trabajo. Para conocer los pasos detallados, 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: enlace con Atlas. Se debe realizar este paso en Atlas después de haber creado la cuenta de Atlas, la organización y el proyecto; implementar el clúster dedicado en este proyecto y se podrá conectar a él.
... include:: /includes/nav/list-migration-page.rst
Selecciona Migrate from a Self-Managed MongoDB Database e inicia el asistente de migración en vivo.
Etapa 2: Provisionamineto del host de migración.
aprovisiona un host de migración en Cloud Manager. Un host de migración ejecuta un MongoDB Agent dedicado que orquesta el proceso de migración en vivo de Cloud Manager a Atlas.
Nota
Si estás migrando una implementación de MongoDB de origen que no ha usado Cloud Manager antes, añade los procesos existentes de MongoDB a Cloud Manager.
En la sección Live Migration: Connect to Atlas de la página Settings de la organización de Cloud Manager, se debe seleccionar Connect to Atlas y pegar el link-token que se ha creado en Atlas. Para aprender más, se debe consultar Conectar 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 comenzar el procedimiento de migración en vivo, añade las direcciones IP o los bloques CIDR de tus hosts de migración a la lista de acceso IP del proyecto. Atlas permite conexiones al clúster de destino solo desde hosts con entradas 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 según se describe en 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 la recopilación de estadísticas de la base de datos para el 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á activada, revisa 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 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.
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 aprender más sobre la seguridad de Atlas, consulte el documento técnico Atlas Security.
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 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
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 puede seleccionar un
M0(nivel gratuito) o un clúster Flex como el clúster de destino para la 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:
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 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.
Evitar cambios en el Namespace
No hagas ningún cambio de namespace durante el proceso de migración, como usar el comando renameCollection o ejecutar un pipeline 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
Considera ejecutar el siguiente procedimiento dos veces. Realiza 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.
Migre su clúster
Importante
Evita realizar cambios en la configuración del clúster de origen mientras el procedimiento de migración en vivo se ejecuta, como remover nodos del set de réplicas o modificar la configuración del tiempo de ejecución de mongod, como featureCompatibilityVersion.
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.
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, crea un clúster de destino en Atlas. Consulta 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 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.
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 se suspende el clúster de origen de la automatización en Cloud Manager, pero se continúa supervisando el clúster de origen con el agente de supervisión, se mostrará Username y Password. Si la implementación requiere autenticación de usuario, se debe proporcionar el nombre de usuario y la contraseña en estos campos. El usuario de base de datos cuyas credenciales se proporcionen debe tener al menos el rol de copia de seguridad en la base de datos admin y debe estar autenticado utilizando tanto SCRAM-SHA-1 como SCRAM-SHA-256.
Si el clúster de origen utiliza TLS/SSL, activa o desactiva el botón Is encryption in transit enabled?.
Si el clúster de origen utiliza TLS/SSL con una Autoridad de Certificación Raíz (CA) personalizada, copia la ruta al archivo CA desde el host de migración y pega esta ruta en el cuadro de texto proporcionado. El archivo debe estar presente en el host de migración para asegurar que el host de migración pueda leer el certificado. Atlas comprueba 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 has configurado una conexión de emparejamiento de VPC entre el host de migración y el set de réplicas de Atlas, la opción VPC Peering está activa. Haz clic en VPC Peering para conectarte mediante el emparejamiento de VPC para la migración en vivo. Si la opción VPC Peering está atenuada, configura una conexión de emparejamiento de VPC antes de comenzar este procedimiento. Para aprender más, consulta Soporte para emparejamiento de VPC y nodos privados.
Si configuraste un nodo privado entre el host de migración y el clúster de Atlas, la opción Private Endpoint está activa. Haz clic en Private Endpoint para conectarte con un nodo privado y, a continuación, selecciona un nodo privado previamente configurado en el menú desplegable. Solo los nodos privados que están en el estado
AVAILABLEson válidos. Si la opción Private Endpoint está desactivada, configura un nodo privado antes de iniciar este procedimiento. Para aprender más, consulta Soporte para el emparejamiento de VPC y los nodos 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, actualiza el MongoDB Agent 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/SSL con una Autoridad de Certificación Raíz (CA) personalizada, el host de migración puede acceder al clúster de origen utilizando TLS/SSL.
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 valida que el clúster de destino dispone de 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, consulta dbStats.
Si la validación falla, verifica el host de migración, la validez de tus direcciones IP externas o el bloque CIDR, y el link-token. También comprueba las credenciales del usuario de base de datos, tus certificados TLS/SSL y la cantidad 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.
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.
API de migración en vivo push
Para ejecutar tareas asociadas con el procedimiento de migración en vivo, consulta API de migración en vivo 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 link-token usando el Atlas CLI, ejecuta el siguiente comando:
atlas liveMigrations link create [options]
Para borrar el link-token que especifiques usando el Atlas CLI, ejecuta 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, consulta la documentación de Atlas CLI para crear enlace a Migraciones en vivo de Atlas y borrar enlace a Migraciones en vivo de Atlas.
Si estás migrando desde Ops Manager, solicita una dirección IP externa y especifícala en el link-token. Para obtener más información, consulta 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, consulta la documentación de Atlas CLI 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 aprender más sobre la sintaxis y los parámetros de los comandos anteriores, consulta la documentación de Atlas CLI para crear migraciones en vivo de Atlas y describir migraciones en vivo de Atlas.
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 aprender más sobre la sintaxis y los parámetros del comando, consulta la documentación de Atlas CLI para la migración en vivo definitiva 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 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, seleccionaHigh Priority.Para Request Summary, por favor 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.