Nota
Esta función está disponible para clústeres M10 o superiores. Para obtener más información sobre las funciones disponibles para los clústeres gratuitos, consulte Límites de los clústeres gratuitos de Atlas, y para los clústeres Flex, consulte Limitaciones de Atlas Flex.
Sus aplicaciones deberían poder gestionar un cambio de servidor principal sin ningún tiempo de inactividad.
En los clústeres Atlas Core:
- Atlas realiza elecciones de conjuntos de réplicas cuando efectúa cambios de configuración, como actualizaciones de parches y eventos de escalado, y cuando se producen fallos.
En los clústeres de Atlas Infinite:
La capa de almacenamiento coordina la conmutación por error en lugar de una elección entre los nodos de cómputo. Un nodo de cómputo en espera se convierte en el nodo principal sin reproducción del oplog ni arranque en frío.
El nodo principal puede cambiar durante el mantenimiento del sistema operativo o de la máquina virtual, el escalado vertical (hacia arriba o hacia abajo), las actualizaciones de la versión de MongoDB y los fallos.
Atlas mantiene su disponibilidad durante los reinicios graduales.
Para aprender a crear una aplicación resiliente, consulte el artículo "Crear una aplicación resiliente con MongoDB Atlas".
Puedes habilitar escrituras reintentables añadiendo retryWrites=true a tu cadena de conexión URI de Atlas. Para obtener más información, consulta Escrituras reintentables.
Puedes usar la Interfaz de Usuario de Atlas y la API para probar la falla del set de réplicas primario en tu clúster Atlas y observar cómo tu aplicación gestiona un cambio de liderazgo del set de réplicas.
Acceso requerido
Para empezar una prueba de conmutación por error, debe tener acceso a Organization Owner, Project Owner, Project Cluster Manager o Project Stream Processing Owner en el proyecto.
Requisitos previos
Antes de probar la falla del principal del set de réplicas, debes cumplir con las siguientes condiciones:
Todos los cambios pendientes en su clúster deben estar completos.
Todos los miembros del clúster deben estar en un estado saludable con datos de supervisión actualizados.
Cada set de réplicas o partición debe tener un nodo principal.
Cualquier nodo del clúster debe tener un atraso de la replicación inferior a 10 segundos.
Todos los miembros del clúster deben tener al menos el 5% de espacio disponible en disco.
Todos los registros de operaciones (oplogs) de los nodos principales deben tener suficiente espacio para tres horas de operación.
Prueba el proceso de failover primario
Importante
Asegúrese de que su clúster Atlas esté en buen estado antes de probar la conmutación por error primaria. De lo contrario, Atlas podría rechazar tu solicitud.
Cuando se envía una solicitud para probar la conmutación por error principal, Atlas simula un evento de conmutación por error. Durante este proceso:
Atlas apaga el primario.actual
Los nodos del set de réplicas celebran una elección para decidir cuál de los secundarios se convertirá en el nuevo primario. En promedio, una elección tarda aproximadamente cinco segundos.
Atlas trae el primario original de vuelta al set de réplicas como un secundario. Cuando el primario antiguo se reincorpora al set de réplicas, se sincronizará con el nuevo primario para actualizarse con cualquier guardar que se haya realizado durante su inactividad.
Las siguientes instrucciones describen el comportamiento de Atlas durante los cambios y al probar la conmutación por error en los clústeres fragmentados:
En los clústeres Atlas Core, es posible que el nodo primario original haya aceptado operaciones de escritura que no se replicaron correctamente en los nodos secundarios antes de su desconexión. Cuando el nodo primario se reincorpora al conjunto de réplicas y comienza la sincronización, revierte esas escrituras no replicadas. Para obtener más información, consulte Reversiones durante la conmutación por error en Atlas.
En los clústeres Atlas Infinite, no se producen reversiones. La capa de almacenamiento confirma las operaciones de escritura, por lo que un antiguo nodo primario no tiene escrituras sin replicar que revertir.
Solo se reinician los procesos
mongosque estén en las mismas instancias que los primarios de los sets de réplicas en el clúster.Los primarios de los conjuntos de réplicas en el clúster particionado son reiniciados en paralelo.
Para iniciar una prueba de failover para el clúster especificado en tu Proyecto mediante la CLI de Atlas, ejecuta el siguiente comando:
atlas clusters failover <clusterName> [options]
Para aprender más sobre la sintaxis del comando y los parámetros, consulta la documentación de la Atlas CLI para conmutación por error de clústeres de Atlas.
Puede usar el Test Failover API endpoint para simular un evento de failover. Para obtener más información sobre el proceso de failover, consulte Proceso de Test Failover.
Para realizar una prueba de conmutación por error primaria utilizando la Interfaz de Usuario de Atlas:
En Atlas, se debe ir a la página Clusters del proyecto.
Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.
Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Clusters en la sección Database.
La página de clústeres se muestra.
Para el clúster en el que deseas realizar pruebas de conmutación por error, haz clic en el botón ....
Haga clic en Test Resilience.
En la ventana modal Test Resilience, haz clic en la pestaña Primary Failover. Atlas muestra los pasos que se requieren para simular un evento de failover. Para obtener más información, consulta Proceso de prueba de failover.
Haz clic en Restart Primary para comenzar la prueba. Atlas muestra los resultados de su proceso de conmutación por error simulado en el modal Test Resilience.
Verificar el failover
Para verificar que la conmutación por error fue exitosa:
En Atlas, ve a la página Clusters de tu proyecto.
Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.
Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Clusters en la sección Database.
La página de clústeres se muestra.
Solucionar problemas de conmutación por error
Si tu aplicación no gestiona el failover de manera adecuada, asegúrate de lo siguiente:
Estás utilizando el Formato de conexión SRV.
Estás utilizando la versión más reciente del controlador.
Ha implementado la lógica de reintento adecuada en su aplicación.