Docs Menu
Docs Home
/

Solucionar problemas de elecciones frecuentes

Los sets de réplicas ocasionalmente se ejecutan elecciones cuando un titular deja el cargo o se vuelve no disponible. Durante una elección, el set de réplicas no puede aceptar escrituras hasta que elija correctamente un nuevo principal, aunque la mayoría de las lecturas pueden continuar en los secundarios si está configurado.

Espere este comportamiento durante conmutaciones por error poco frecuentes o mantenimientos programados. Sin embargo, las elecciones frecuentes, donde el primario cambia a menudo durante la normal operación, provocan interrupciones repetidas en la escritura y, en algunos casos, rollbacks de datos no confirmados.

Esta página contiene problemas y resoluciones comunes para elecciones recurrentes, lo que garantiza un diagnóstico rápido y evita interrupciones en los guardados de la aplicación. Si necesita soporte adicional después de revisar las siguientes secciones, contacte a Soporte Técnico.

Los clústeres saludables solo ven elecciones durante eventos poco frecuentes y esperados. Las elecciones suelen celebrarse durante los siguientes escenarios:

Verifica que tu implementación experimente elecciones frecuentes fuera de estos escenarios ejecutando el método replSetGetStatus o rs.status() varias veces durante un período determinado, como dentro de una hora o durante el día. Compare el valor reportado del primario _id cada vez para rastrear si y cuándo cambia el nodo primario, lo que significa que se produjo una elección.

Nota

Si ves una alerta TOO_MANY_ELECTIONS en Ops Manager, probablemente estés experimentando elecciones frecuentes.

También puedes consultar los mensajes del registro de tu implementación para las entradas donde el valor del componente ("c") sea ELECTION. Si tus registros muestran múltiples ocurrencias de los siguientes mensajes en intervalos cortos, como varias veces por hora o día sin mantenimiento planificado, esto generalmente indica un set de réplicas no saludable causado por inestabilidad de red, hosts no saludables o una mala configuración:

Mensaje
Descripción

"Iniciando una elección, ya que no hemos visto NINGÚN PRIMARIO en el periodo de tiempo de espera de la elección"

Registrado por otros nodos cuando el principal se retira.

"transición a PRIMARIO desde SECUNDARIO"

Un nuevo cuidador primario toma el control.

"no puede ver la mayoría del conjunto, cediendo el control primario"

La primaria anterior se convierte en secundaria.

La siguiente sección describe problemas comunes que pueden hacer que un set de réplicas realice elecciones frecuentes inesperadas. Antes de contactar al soporte, verifica si los siguientes problemas causan elecciones frecuentes en su set de réplicas.

Las consultas intensivas, grandes agregaciones y tareas en segundo plano como la construcción de índices o las copias de seguridad pueden causar un alto uso de la CPU, latencia o fallos en el disco, y presión en la memoria. El agotamiento de recursos puede causar elecciones frecuentes porque el primario puede volverse no receptivo o incapaz de procesar los latidos a tiempo.

Para comprobar si tu implementación experimenta un agotamiento de recursos debido a consultas ineficientes:

  1. Busca en tus registros entradas donde el valor del componente ("c") sea COMMAND.

  2. Para cada entrada, el campo bytesRead indica cuántos bytes lee un comando determinado. Preste atención a los comandos con valores grandes de bytesRead.

  3. Si las marcas de tiempo de tus consultas ineficientes ocurren cerca de las marcas de tiempo de múltiples elecciones, es probable que las consultas ineficientes estén causando elecciones frecuentes.

Utilice los siguientes recursos para optimizar sus consultas:

  • Gestiona tu carga de trabajo de manera más eficiente utilizando Índices compuestos.

  • Consulte nuestra Directriz ESR para crear nuevos índices.

  • En Atlas, revisa tu asesor de rendimiento periódicamente para obtener sugerencias de índices basadas en la carga de trabajo más reciente.

Los sets de réplicas convocan elecciones continuamente hasta que eligen al nodo con la prioridad más alta. Si no estableces las prioridades de los nodos adecuadamente, las elecciones pueden ocurrir con mayor frecuencia y nodos inesperados pueden convertirse en el principal.

Para comprobar los valores de prioridad de cada nodo, ejecute el comando replSetGetConfig o el método rs.conf(). El siguiente ejemplo muestra el output (rs.conf()) del método para un set de réplicas con prioridades mal configuradas:

rs.conf().members
[
{
_id: 0,
host: "rs0-0.example.net:27017",
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 1,
tags: { dc: "primaryDC" },
secondaryDelaySecs: Long(0),
votes: 1
},
{
_id: 1,
host: "rs0-1.example.net:27017",
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 10,
tags: { dc: "remoteDC1" },
secondaryDelaySecs: Long(0),
votes: 1
},
{
_id: 2,
host: "rs0-2.example.net:27017",
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 9,
tags: { dc: "remoteDC2" },
secondaryDelaySecs: Long(0),
votes: 1
},
{
_id: 3,
host: "rs0-3.example.net:27017",
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 8,
tags: { dc: "analyticsDC" },
secondaryDelaySecs: Long(0),
votes: 1
}
]

En el ejemplo anterior, el primario actual tiene menor prioridad que los otros tres nodos. Si un secundario de alta prioridad está sano y en estado SECUNDARIO, puede desencadenar una elección para asumir como primario.

Asegúrate de configurar las prioridades para los miembros de tu set de réplicas de manera adecuada:

  • Asigne la máxima prioridad al servidor que desee que sirva de forma constante como primario

  • Asigna prioridades predeterminadas o más bajas a otros nodos para reducir la probabilidad de que se conviertan en primarios

  • Asignar a los nodos con un alto atraso de la replicación una prioridad baja

Para comprobar los ajustes de configuración de su set de réplicas, ejecute el comando replSetGetConfig o el método rs.conf(). El siguiente ejemplo muestra un set de réplicas con electionTimeoutMillis configurado demasiado bajo:

rs.conf().settings
{
chainingAllowed: true,
heartbeatIntervalMillis: 2000,
heartbeatTimeoutSecs: 10,
electionTimeoutMillis: 1500, // lower than a single heartbeat cycle
catchUpTimeoutMillis: 2000,
getLastErrorModes: { },
getLastErrorDefaults: {
w: 1,
wtimeout: 0
},
replicaSetId: ObjectId("58858acc1f5609ed986b641b")
}

Asegúrese de que el valor para settings.electionTimeoutMillis no sea demasiado bajo. En el ejemplo anterior, el valor settings.electionTimeoutMillis es inferior al valor settings.heartbeatIntervalMillis. Esto significa que un nodo puede declarar el primario como "inactivo" antes de que complete un intervalo completo de latido del corazón, causando elecciones innecesarias.

Si tu implementación experimenta una partición de red o tus nodos experimentan retrasos en los mensajes de latidos, los secundarios pueden ver incorrectamente al primario como no disponible e iniciar elecciones.

Para verificar que estás experimentando particiones de red:

  1. Verifica la aparición común de los siguientes mensajes en tus registros:

    Mensaje
    Descripción

    "Iniciando una elección, ya que no hemos visto NINGÚN PRIMARIO en el periodo de tiempo de espera de la elección"

    Un secundario inició una elección porque no recibió pulsos del primario dentro de la ventana de tiempo de espera configurada.

    "no puede ver la mayoría del conjunto, cediendo el control primario"

    La principal se desactivó porque no puede comunicarse con la mayoría de las secundarias con derecho a voto.

  2. Ejecuta rs.status() o replSetGetStatus desde diferentes nodos para mostrar diferentes vistas de cuáles nodos son alcanzables, lo que indica una división entre subconjuntos de nodos.

Para ayudar a restaurar la conectividad después de una partición:

  • Verifica las configuraciones de tus firewalls en busca de cualquier regla que pueda bloquear la comunicación entre los nodos.

  • Verificar los nombres de host DNS.

  • Asegúrate de agregar tu dirección IP a tu lista de acceso IP.

Después de solucionar la causa raíz, confirme que las elecciones frecuentes ya no ocurren volviendo a ejecutar rs.status(). La salida muestra exactamente un nodo en el estado primario, y que el primario se mantiene estable durante su ventana normal de observación sin cambios no planificados.

También puedes consultar tus registros de implementación. Busca los mensajes de registro mencionados anteriormente en tus registros de implementación para asegurarte de que las elecciones no ocurran varias veces en intervalos cortos.

Si aún no puedes resolver tu problema, contacta al soporte técnico con la siguiente información de diagnóstico:

  • Mensajes de registro relevantes durante el período de tiempo afectado

  • rs.config() salida

  • rs.status() salida

Volver

Versión del protocolo de set de réplicas

En esta página