Solución de problemas de conjuntos de réplica sin primario

En ocasiones, los conjuntos de réplicas pueden entrar en un estado en el que no existe un nodo primario, normalmente durante las elecciones. Sin embargo, cuando no existe un nodo primario durante un período prolongado, el conjunto de réplicas no puede aceptar escrituras.

Esta página contiene problemas comunes y soluciones para solucionar problemas de conjuntos de réplicas que no tienen un nodo primario durante un período prolongado. Si necesita asistencia adicional después de revisar las siguientes secciones, póngase en contacto con nosotros. Apoyo técnico.

Comprobaciones de requisitos previos

Verifique que su implementación no tenga un nodo principal ejecutando el siguiente comando: replSetGetStatus rs.status() Método o. El siguiente ejemplo muestra el resultado del método para un conjunto de réplicas sin nodo rs.status() primario:

rs.status().members

[
   {
      _id: 0,
      name: 'localhost:27018',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6,
      self: true,
      lastHeartbeatMessage: ''
   },
   {
      _id: 1,
      name: 'localhost:27019',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6
             },
             {
      _id: 2,
      name: 'localhost:27020',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6
             }
     ]

Nota

En algunos casos, puede que vea que la rs.status() salida muestra elstateStr valor de algunos UNKNOWN miembros DOWN como o.

Revisar los mensajes de registro

Revise los mensajes de registro de su implementación en busca de entradas donde el"c" valor del ELECTION componente () sea. Aquí, podría encontrar intentos repetidos de iniciar elecciones que fallan con los siguientes mensajes en el "msg" campo:

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.
"Recibimos votos insuficientes"	Indica que la mayoría de los nodos no respondieron a la solicitud de elección. Es posible que algunos miembros estén inactivos o que se haya producido una partición de la red.
"No puedo ver a la mayoría del grupo, renuncio a la primaria"	Es posible que algunos miembros no estén disponibles o que se haya producido una partición de la red.

Problemas comunes y sus soluciones

La siguiente sección describe problemas comunes que pueden dificultar la elección de un nuevo nodo primario en un conjunto de réplicas y cómo solucionarlos. Antes de contactar con el soporte técnico, compruebe si alguno de los siguientes problemas impide que su implementación elija un nodo primario.

Partición de red

Si su implementación experimenta una partición de red, los nodos no pueden comunicarse entre sí, lo que impide que elijan un nodo principal.

Para verificar si su implementación se ve afectada por una partición de red, ejecute el método replSetGetStatus o desde diferentes nodos. Según la salida de cada nodo, identifique qué nodos se encuentran a cada lado de la partición.rs.status()

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

Verifique la configuración de su firewall para detectar cualquier regla que bloquee 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.

Tip

Una vez que la mayoría de los nodos pueden comunicarse entre sí, MongoDB elige automáticamente un nodo principal y reanuda la escritura con normalidad.

No hay escuelas secundarias elegibles para ascender

Asegúrese de que su centro de datos principal cuente con un quórum de miembros con derecho a voto y con miembros que puedan ser primarios. Si el nodo primario de su conjunto de réplicas falla y ninguno de los nodos secundarios es elegido como primario, compruebe que los nodos restantes no sean todos 0 miembros de prioridad.

Para comprobar los valores de prioridad de cada miembro, ejecute el replSetGetConfig comando o rs.conf() el método:

// Returns an array of documents corresponding with each member in your replica set
rs.conf().members

[
   ...
   {
      _id: 1,
      host: localhost:27019,
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 0,
      tags: {},
      secondaryDelaySecs: Long('0'),
      votes: 1
   },
   ...
]

Si ningún elemento secundario puede convertirse en principal debido a su prioridad, actualice el members[n].priority valor de uno o más elementos secundarios. Para obtener instrucciones detalladas, consulte Ajustar la prioridad de un miembro del conjunto de réplicas autogestionado.

Agotamiento de recursos

Si su implementación tiene cargas de trabajo con mucha escritura, demasiados índices o procesos de mantenimiento que ocupan una cantidad significativa de espacio en disco, podría sobrecargar sus nodos y provocar que fallen.

Para recuperar espacio en disco, tenga en cuenta lo siguiente:

Eliminar colecciones o bases de datos no utilizadas.
Eliminar índices duplicados o no utilizados.

Para supervisar el uso del disco:

En Atlas, puedes ver el Disk Usage gráfico, disponible en Monitoreo de clústeres.
En implementaciones autogestionadas, ejecute el dbStats comando o db.stats() el método.

Pérdida de la mayoría

Si varios miembros con derecho a voto fallan y el conjunto de réplicas pierde su mayoría, la salida rs.status() puede mostrar que todos los miembros están en el estado SECONDARY o RECOVERING. Los siguientes escenarios pueden causar la pérdida de la mayoría:

Mantenimiento rodante realizado incorrectamente

Por ejemplo, consideremos un conjunto de réplicas de tres miembros donde dos de ellos se desconectan para mantenimiento simultáneamente. En este caso, el conjunto de réplicas pierde su mayoría y no puede elegir un nuevo nodo primario hasta que el tercer miembro vuelva a estar operativo.

Para evitar esta situación, asegúrese de realizar el mantenimiento progresivo de forma secuencial, comenzando por los miembros secundarios y terminando con el principal. Esto garantiza que siempre haya un miembro principal disponible. Para obtener orientación sobre el mantenimiento de conjuntos de réplicas, consulte la sección «Realizar el mantenimiento de los miembros de un conjunto de réplicas autogestionado».

Topología de clúster con recursos insuficientes

Por ejemplo, consideremos una implementación con dos miembros que contienen datos y un nodo oculto sin derecho a voto. Si uno de los miembros que contienen datos falla, los miembros restantes no pueden formar una mayoría.

En una topología de árbitro primario-secundario (PSA) que utiliza "majority" la preocupación de escritura, si el secundario se cae por mantenimiento, las escrituras se detienen. El primario no puede obtener la confirmación de la mayoría porque solo uno de los dos miembros votantes portadores de datos está disponible. Sin wtimeout configurado en las operaciones de escritura, las escrituras se bloquean indefinidamente. Para mitigar esto:

Limite las operaciones de escritura durante la ventana de mantenimiento para reducir el volumen de escrituras bloqueadas.
Establezca el parámetro wtimeout en las operaciones de escritura que utilizan la preocupación de escritura "majority" para evitar que las escrituras se bloqueen indefinidamente.

Para obtener más detalles sobre cómo mitigar los problemas de rendimiento en las topologías PSA,consulte Mitigar los problemas de rendimiento con un conjunto de réplicas PSA autogestionado.

En una topología primaria-secundaria-secundaria-secundaria-árbitro (PSSSA), ubicar a la mayoría de los miembros con derecho a voto en un único centro de datos o sitio de recuperación ante desastres (DR) conlleva el riesgo de perder dicha mayoría. Si esa región falla por completo, los miembros restantes no podrán formar una mayoría ni elegir un árbitro principal. Distribuya los miembros con derecho a voto entre las regiones para que se mantenga una mayoría disponible tras el fallo de una sola región. Para obtener más información, consulte la sección "Concienciación sobre centros de datos".

Verificar resolución

Una vez que se restablezca su implementación y se elija un nuevo primario, la salida rs.status() muestra que uno de sus miembros está en el estado PRIMARY.

Diagnósticos para recopilar para obtener más apoyo

Si no puede resolver su problema, póngase en contacto con el soporte técnico y facilítele la siguiente información de diagnóstico:

Mensajes de registro relevantes
rs.config() salida
rs.status() salida

Temas relacionados

Obtén más información

Volver

Elecciones frecuentes

atraso de la replicación