Ocasionalmente se realizan lanzamientos de réplicas. elecciones cuando un nodo primario cede su puesto o deja de estar disponible. Durante una elección, el conjunto de réplicas no puede aceptar escrituras hasta que elija con éxito un nuevo nodo primario, aunque la mayoría de las lecturas pueden continuar en los nodos secundarios si están configurados.
Este comportamiento es previsible durante conmutaciones por error poco frecuentes o mantenimientos planificados. Sin embargo, las elecciones frecuentes, en las que el servidor principal cambia a menudo durante el funcionamiento normal, provocan interrupciones de escritura repetidas y, en algunos casos, reversiones de datos no confirmados.
Esta página contiene problemas comunes y sus soluciones para elecciones frecuentes, lo que permite un diagnóstico rápido y evita interrupciones en la escritura de la aplicación. Si necesita ayuda adicional después de revisar las siguientes secciones, póngase en contacto con el soporte técnico.
Comprobaciones de requisitos previos
En los clústeres saludables, las elecciones solo se producen durante eventos poco frecuentes y previsibles. Normalmente, las elecciones tienen lugar en los siguientes escenarios:
Configuración inicial
Operaciones de mantenimiento, tales como
rs.stepDown()orrs.reconfig()Nuevas incorporaciones de miembros con
rs.add()Indisponibilidad principal durante más de los
timeoutconfigurados, donde el valor predeterminado es 10 segundos.
Verifique que su implementación experimente elecciones frecuentes fuera de estos escenarios ejecutando el método o varias veces durante un período determinado, como en una hora o a lo largo del día. Compare el valor del nodo primario replSetGetStatus rs.status() informado _id cada vez para rastrear si el nodo primario cambia y cuándo lo hace, lo que indicaría que se produjo una elección.
Nota
Si ve una alerta TOO_MANY_ELECTIONS en Ops Manager, es probable que esté experimentando elecciones frecuentes.
Revisar los mensajes de registro
También puede consultar los mensajes de registro de su implementación para ver las entradas donde el"c" valor del ELECTION componente () sea. Si sus registros muestran varias ocurrencias de los siguientes mensajes en intervalos cortos, como varias veces por hora o por día sin mantenimiento planificado, esto generalmente indica un conjunto de réplicas en mal estado causado por inestabilidad de la red, hosts en mal estado o una configuración incorrecta:
Mensaje | Descripción |
|---|---|
"Iniciar unas elecciones, ya que no hemos visto primarias en el período de pausa electoral". | Registrado por otros miembros cuando el titular principal renuncia. |
"Transición de SECUNDARIA a PRIMARIA" | Toma el relevo una nueva elección primaria. |
"No puedo ver a la mayoría del grupo, renuncio a la primaria" | La escuela primaria anterior se convierte en secundaria. |
Problemas comunes y sus soluciones
La siguiente sección describe problemas comunes que pueden provocar elecciones frecuentes e inesperadas en un conjunto de réplicas. Antes de contactar con el servicio de asistencia, compruebe si alguno de los siguientes problemas causa elecciones frecuentes en su conjunto de réplicas.
Agotamiento de recursos
Las consultas intensivas, las grandes agregaciones y las tareas en segundo plano, como la creación de índices o las copias de seguridad, pueden provocar un alto consumo de CPU, latencia o fallos en el disco y presión sobre la memoria. El agotamiento de los recursos puede causar elecciones frecuentes, ya que el servidor principal puede dejar de responder o ser incapaz de procesar las señales de actividad a tiempo.
Consultas ineficientes
Para comprobar si su implementación experimenta un agotamiento de recursos debido a consultas ineficientes:
Busque entradas en sus registros donde el valor del componente ("c")
COMMANDsea.Para cada entrada, el campo
bytesReadindica cuántos bytes lee un comando determinado. Presta atención a los comandos con valoresbytesReadgrandes.Si las marcas de tiempo de sus consultas ineficientes coinciden con las marcas de tiempo de varias elecciones, es probable que las consultas ineficientes sean la causa de sus elecciones frecuentes.
Utilice los siguientes recursos para optimizar sus consultas:
Gestiona tu carga de trabajo de forma más eficiente utilizando índices compuestos.
Consulte nuestra Guía ESR para crear nuevos índices.
En Atlas, revise su Elasesor de rendimiento le proporcionará sugerencias de índices periódicamente, basadas en su carga de trabajo más reciente.
Configuración incorrecta del conjunto de réplicas
Prioridad del nodo
Los conjuntos de réplicas convocan elecciones continuamente hasta que eligen al miembro con la prioridad más alta. Si no se establecen las prioridades de los miembros adecuadamente, las elecciones pueden ocurrir con mayor frecuencia, y miembros inesperados pueden convertirse en los principales.
Para comprobar los valores de prioridad de cada miembro, ejecute el replSetGetConfig comando o rs.conf() el método. El siguiente ejemplo muestra el resultado del rs.conf() método para un conjunto de réplicas con prioridades configuradas incorrectamente:
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, la primaria actual tiene menor prioridad que las otras tres. Si una secundaria de alta prioridad está en buen estado y en estado SECUNDARIO, puede desencadenar una elección para convertirse en primaria.
Asegúrese de configurar adecuadamente las prioridades para los miembros de su conjunto de réplicas:
Asigne la máxima prioridad al servidor que desea que funcione de forma constante como servidor principal.
Asigne prioridades predeterminadas o más bajas a otros miembros para reducir la probabilidad de que se conviertan en principales.
Asignar prioridad baja a los nodos con un alto retraso de replicación
Configuración del set de réplicas
Para comprobar la configuración de su conjunto replSetGetConfig de réplicas, ejecute el comando o rs.conf() el método. El siguiente ejemplo muestra un conjunto 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 settings.electionTimeoutMillis de que el valor de no sea demasiado bajo. En el ejemplo anterior, el settings.electionTimeoutMillis valor de es inferior a. Esto significa que un nodo puede declarar el nodo primario como "inactivo" antes de que se complete un intervalo de latido completo, lo que provoca elecciones settings.heartbeatIntervalMillis innecesarias.
Particionamiento de red o latencia
Si su implementación experimenta particiones de red o sus nodos experimentan retrasos en los mensajes de latido, los nodos secundarios pueden considerar erróneamente al nodo primario como no disponible e iniciar elecciones.
Para verificar si está experimentando particiones de red:
Comprueba si aparecen con frecuencia los siguientes mensajes en tus registros:
MensajeDescripción"Iniciar unas elecciones, ya que no hemos visto primarias en el período de pausa electoral".
Un nodo secundario inició una elección porque no recibió señales de actividad del nodo primario dentro del plazo de tiempo de espera configurado.
"No puedo ver a la mayoría del grupo, renuncio a la primaria"
La elección primaria se suspendió porque no puede comunicarse con la mayoría de las elecciones secundarias.
Ejecute
rs.status()o desde diferentes nodos para mostrar diferentes vistas de qué miembros son accesibles, lo que indica una división entre subconjuntos dereplSetGetStatusnodos.
Para ayudar a restablecer la conectividad después de una partición:
Verifique la configuración de sus firewalls para detectar cualquier regla que pueda bloquear la comunicación entre los miembros.
Compruebe los nombres de host DNS.
Asegúrese de agregar su dirección IP a su lista de control de acceso IP.
Verificar resolución
Tras solucionar la causa raíz, confirme que ya no se producen elecciones frecuentes volviendo a ejecutar rs.status(). El resultado muestra exactamente un miembro en el estado primario, y que este se mantiene estable durante el período de observación habitual sin cambios imprevistos.
También puede consultar los registros de implementación. Busque los mensajes de registro mencionados anteriormente en los registros de implementación para asegurarse de que las elecciones no se produzcan varias veces en intervalos cortos.
Diagnósticos para recopilar para obtener más apoyo
Si aún no logra resolver su problema, comuníquese con el soporte técnico y proporcione la siguiente información de diagnóstico:
Mensajes de registro relevantes durante el período de tiempo afectado
rs.config()salidars.status()salida