Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Migrar en vivo (Push) un clúster supervisado por Cloud Manager a Atlas

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.

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.

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

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

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

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.

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.

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.

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.

"Para migrar en vivo la implementación a Atlas, se debe generar un link-token, aprovisionar un host de migración e iniciar la migración en vivo".

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.

  • Etapa 2: Provisionamineto del host de migración.

  • Etapa 3: comienza la migración. En Atlas, sigue los pasos del asistente para iniciar el proceso de migración en vivo.

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.

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.

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.

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.

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.

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 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:

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.

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.

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:

    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 featureCompatibilityVersion mientras la migración en vivo de Atlas está en ejecución.

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.

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.

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.

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.

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.

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.

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

  2. Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.

  3. En la barra lateral, haz clic en Migration en la sección Services.

El centro de migración muestra.

2
  1. 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.

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

3
  1. Haz clic en Generate Link-Token. Atlas muestra la página para generar un link-token.

  2. Haz clic en Next para ver una página que contiene el link-token generado.

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

  4. Haga clic en Done.

4
  1. 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.

  2. Haz clic en Settings en el panel de navegación izquierdo.

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

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

5

Si aún no lo ha hecho, cree un clúster de destino en Atlas.Consulte Acceso requerido.

6
  1. Haga clic en Select Target Cluster from Projects.

  2. Ir al proyecto del clúster de Atlas de destino y localizar el clúster de destino.

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

  4. 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:

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

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

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

8

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

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

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

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.

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:

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.

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.

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.

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.

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:

1
  1. Si aún no se muestra, selecciona la organización deseada en el menú Organizations de la barra de navegación.

  2. Haga clic en el icono Support en la barra de navegación.

  3. Haga clic en View plan.

Se muestra la página de soporte.

2
  1. Haga clic en Request Support.

  2. Para Issue Category, seleccione Help with live migration.

  3. Para Priority, seleccione la prioridad adecuada. Para preguntas, seleccione Medium Priority. Si hubo un fallo en la migración, seleccione High Priority.

  4. Para Request Summary, incluya Live Migration en su resumen.

  5. Para More details, incluye cualquier otro detalle relevante sobre la pregunta o el error de migración.

  6. Haz clic en el botón Request Support para enviar el formulario.