Solucionar problemas de sets de réplicas sin primario

Verificar mensajes de registro

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

Partición de red

Si tu implementación experimenta una partición de red, los nodos no pueden comunicarse entre sí, lo que les impide elegir un primario.

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

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

• Verifique las configuraciones del cortafuegos para detectar cualquier regla que bloquee la comunicación entre nodos.

• Verificar los nombres de host DNS.

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

Una vez que la mayoría de los nodos pueden conectarse entre sí, MongoDB elige automáticamente un nodo primario y reanuda las escrituras de manera normal.

No existe ningún secundario elegible para ascender

Asegúrate de que tu centro de datos principal contenga tanto un quórum de nodos con derecho a voto como nodos que sean elegibles para ser primarios. Si el primario de tu set de réplicas se cae y ninguno de los secundarios es elegido para convertirse en primario, verifica que los nodos restantes no sean todos nodos de prioridad 0.

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

// 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 ninguno de los secundarios es elegible para convertirse en primario debido a su prioridad, actualiza el valor members[n].priority de uno o varios secundarios. Para obtener instrucciones detalladas, consulta Ajustar la prioridad para un miembro de set de réplicas autogestionado.

Agotamiento de recursos

Si tu implementación tiene cargas de trabajo intensivas en escritura, demasiados índices o procesos de mantenimiento que ocupan un espacio significativo en disco, podrías sobrecargar tus nodos y hacer que fallen.

Para reclamar espacio en disco, considere:

• Descartando colecciones o bases de datos no utilizadas.

• Eliminando los índices duplicados o no utilizados.

• Si tiene programado periodo de mantenimiento, considera habilitar la compactación en segundo plano con el autoCompact.

  Advertencia

  Ejecute autoCompact sólo durante períodos de bajo tráfico, como en un periodo de mantenimiento. En bases de datos de alto tráfico, la compactación en segundo plano puede potencialmente retrasar o impedir tareas operativas como la realización de copias de seguridad. Para obtener más información sobre el impacto en el rendimiento y otras consideraciones antes de habilitar la compactación en segundo plano, consulte Comportamiento de autoCompactación.

Para supervisar el uso del disco:

• En Atlas, puede ver el Disk Usage gráfica, disponible en supervisión de clúster.

• En las implementaciones autogestionadas, ejecute el comando dbStats o el método db.stats().

Pérdida de la mayoría

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