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.
Comprobaciones previas
Los clústeres saludables solo ven elecciones durante eventos poco frecuentes y esperados. Las elecciones suelen celebrarse durante los siguientes escenarios:
Configuración inicial
Las operaciones de mantenimiento, como por ejemplo
rs.stepDown()orrs.reconfig()Nuevas incorporaciones de nodos con
rs.add()Indisponibilidad primaria durante más del tiempo configurado
timeout, donde el valor por defecto es 10 segundos
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.
Verificar mensajes de registro
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. |
Problemas comunes y soluciones
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.
Agotamiento de recursos
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.
Consultas ineficientes
Para comprobar si tu implementación experimenta un agotamiento de recursos debido a consultas ineficientes:
Busca en tus registros entradas donde el valor del componente ("c") sea
COMMAND.Para cada entrada, el campo
bytesReadindica cuántos bytes lee un comando determinado. Preste atención a los comandos con valores grandes debytesRead.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.
Configuración incorrecta del set de réplicas
Prioridad del nodo
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
Configuración del set de réplicas
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.
Particionamiento de red o latencia
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:
Verifica la aparición común de los siguientes mensajes en tus registros:
MensajeDescripció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.
Ejecuta
rs.status()oreplSetGetStatusdesde 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.
Verificar resolución
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.
Diagnósticos a recopilar para más apoyo
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()salidars.status()salida