Prueba de conmutación por error primaria

Nota

Esta funcionalidad está disponible para los clústeres de M10 o superiores. Para aprender más sobre qué funcionalidad está disponible para clúster gratuitos, consulte Atlas Free Cluster Limits, y para clúster Flex, consulte Atlas Flex Limitations.

Sus aplicaciones deberían gestionar un cambio de primario sin ningún tiempo de inactividad.

En los clústeres de 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 Atlas Infinite clúster:

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 primario sin reproducción de oplog ni un arranque en frío.
El nodo primario puede cambiar durante el mantenimiento del sistema operativo o de la VM, el escalado vertical hacia arriba o hacia abajo, las actualizaciones de la versión de MongoDB y los fallos.
Atlas mantiene la disponibilidad durante los reinicios en secuencia.

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 el fallo del conjunto de réplicas principal, debe cumplir 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 desactiva el servidor principal actual.
Los miembros del grupo de réplicas celebran una elección para decidir cuál de las escuelas secundarias se convertirá en la nueva escuela primaria. En promedio, una elección dura 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 de Atlas Core, el primario original podría haber aceptado operaciones de guardar que no se replicaron correctamente a los secundarios antes de que se retirara. Cuando ese primario se reincorpora al set de réplicas y comienza a sincronizarse, revierte esos guardares no replicados. Para aprender más, consulta Rollbacks durante Failover en Atlas.
En los clústeres Atlas Infinite, no se producen rollback. La capa de almacenamiento confirma las operaciones de guardar, por lo tanto, un nodo primario anterior no tiene guardar no replicadas que revertir.
Solo se reinician los procesos mongos que se encuentran en las mismas instancias que los primarios de los conjuntos de réplicas en el clúster fragmentado.
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 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 conmutación por error de clústeres de Atlas.

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.

Observa los nodos.

Haz clic en el nombre del clúster para el que realizaste la prueba de conmutación por error.
Observa los siguientes cambios en la lista de nodos en la pestaña Overview:
- El nodo original PRIMARY ahora es un nodo SECONDARY.
- Un nodo SECONDARY anterior ahora es el nodo PRIMARY.

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.

Volver

Resiliencia de las pruebas

Simular una Interrupción del servicio regional