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

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

  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 aprender más, consulte rollback durante el traspaso de Atlas.

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

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

  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.