Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
MongoDB Branding Shape
Click here >
Docs Menu

Prueba de conmutación por error primaria

Nota

Esta funcionalidad no está disponible para clústeres gratuitos ni flexibles. Para aprender más sobre qué funcionalidades no están disponibles, consulte Límites del clúster gratuito de Atlas.

Atlas realiza elecciones de set de réplicas cuando realiza cambios de configuración, como actualizaciones de parches, eventos de escalado y cuando ocurren errores. Tus aplicaciones deben gestionar los sets de réplicas sin tiempo de inactividad. Para aprender cómo compilar una aplicación resiliente, consulta Compilar 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.

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

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:

  1. Atlas apaga el primario.actual

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

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

  • Si el primario original aceptó operaciones de escritura que no se habían replicado correctamente en los secundarios cuando el primario fue degradado, el primario revierte esas operaciones de escritura cuando se reincorpora al set de réplicas y comienza a sincronizar. Para obtener más información, consulte Reversiones durante el traspaso de set de réplicas. Póngase en contacto con Soporte de MongoDB para obtener ayuda con la resolución de retrocesos.

  • Solo se reinician los procesos mongos que 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 aprender más sobre el proceso de conmutación por error, consulta el 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, se debe ir a la página Clusters del 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 deseas realizar pruebas de conmutación por error, haz 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. 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.

Para verificar que la conmutación por error fue 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. Haz clic en el nombre del clúster para el que realizaste la prueba de conmutación por error.

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

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.