Docs Menu
Docs Home
/ /

Prueba de conmutación por error primaria

Nota

Esta función no está disponible para M0 Clústeres gratuitos y clústeres Flex. Para obtener más información sobre las funciones que no están disponibles, consulte Límites de Atlas M0 (clúster libre).

Atlas lleva a cabo Elecciones de conjuntos de réplicas al realizar cambios de configuración, como actualizaciones de parches, eventos de escalado y fallos. Sus aplicaciones deberían gestionar las elecciones de conjuntos de réplicas sin interrupciones. Para aprender a crear una aplicación resiliente, consulte "Crear una aplicación resiliente con MongoDB Atlas".

Puede habilitar las escrituras reintentables añadiendo retryWrites=true a la cadena de conexión URI de Atlas. Para obtener más información, consulte Escrituras reintentables.

Puede utilizar la interfaz de usuario Atlas y API para probar la falla del conjunto de réplicas principal en su clúster Atlas y observar cómo su aplicación maneja una conmutación por error del conjunto de réplicas.

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.

Antes de probar la falla del conjunto de réplicas principal, debe cumplir las siguientes condiciones:

  • Todos los cambios pendientes en su clúster deben completarse.

  • Todos los miembros del clúster deben estar en un estado saludable con datos de monitoreo actualizados.

  • Cada conjunto de réplicas o fragmento debe tener un nodo principal.

  • Cualquier miembro del clúster debe tener un retraso de replicación de menos de 10segundos.

  • Todos los miembros de su clúster deben tener al menos un 5% de espacio disponible en disco restante.

  • Todos los registros de operaciones del nodo principal deben tener suficiente espacio para una operación de tres horas.

Importante

Asegúrese de que su clúster Atlas esté en buen estado antes de probar la conmutación por error principal. De lo contrario, Atlas podría rechazar su solicitud.

Al enviar una solicitud para probar la conmutación por error principal, Atlas simula un evento de conmutación por error. Durante este proceso:

  1. Atlas cierra la primaria actual.

  2. Los miembros del conjunto de réplicas realizan una elección para elegir cuál de los secundarios se convertirá en el nuevo primario.

  3. Atlas reincorpora el servidor principal original al conjunto de réplicas como secundario. Cuando el servidor principal antiguo se reincorpora al conjunto de réplicas, se sincroniza con el nuevo para recuperar las escrituras realizadas 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:

  • Si el servidor primario original aceptó operaciones de escritura que no se replicaron correctamente en los servidores secundarios cuando el servidor primario se retiró, este las revierte al reincorporarse al conjunto de réplicas y comenzar la sincronización. Para obtener más información, consulte Reversiones durante la conmutación por error del conjunto de réplicas. Contacte con el soporte de MongoDB para obtener ayuda con la resolución de reversiones.

  • Solo mongos se reinician los procesos que están en las mismas instancias que los primarios de los conjuntos de réplicas en el clúster fragmentado.

  • Las réplicas primarias de los conjuntos de réplicas en el clúster fragmentado se reinician en paralelo.

Para iniciar una prueba de conmutación por error para el clúster especificado en su proyecto mediante la CLI de Atlas, ejecute el siguiente comando:

atlas clusters failover <clusterName> [options]

Para obtener más información sobre la sintaxis y los parámetros del comando, consulte la documentación de la CLI de Atlas para la conmutación por error de clústeres de Atlas.

Puede usar el punto final de la API de prueba de conmutación por error para simular un evento de conmutación por error. Para obtener más información sobre el proceso de conmutación por error, consulte Proceso de prueba de conmutación por error.

Para realizar una prueba de conmutación por error primaria utilizando la Interfaz de Usuario de Atlas:

  1. En Atlas, vaya a la Clusters Página para su proyecto.

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

    2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

    3. En la barra lateral, haz clic en Clusters en la sección Database.

      La página de clústeres se muestra.

  2. Para el clúster en el que desea realizar pruebas de conmutación por error, haga clic en el botón ....

  3. Haga clic en Test Resilience.

  4. En el Test Resilience modal, haga clic en la Primary Failover pestaña. Atlas muestra los pasos necesarios para simular un evento de conmutación por error. Para obtener más información, consulte Probar el proceso de conmutación por error.

  5. Haga clic en Restart Primary para iniciar la prueba. Atlas muestra los resultados de su simulación de conmutación por error en el cuadro modal Test Resilience.

Para verificar que la conmutación por error sea exitosa:

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

  2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

  3. En la barra lateral, haz clic en Clusters en la sección Database.

La página de clústeres se muestra.

2
  1. Haga clic en el nombre del clúster para el que realizó la prueba de conmutación por error.

  2. Observe los siguientes cambios en la lista de nodos en la pestaña Overview:

    • El nodo PRIMARY original ahora es un nodo SECONDARY.

    • Un nodo SECONDARY anterior ahora es el nodo PRIMARY.

Si su aplicación no gestiona la conmutación por error correctamente, asegúrese de lo siguiente:

  • Estás utilizando el formato de conexión SRV.

  • Estás utilizando la última versión del controlador.

  • Ha implementado la lógica de reintento adecuada en su aplicación.

Volver

Resiliencia de las pruebas

En esta página