☰

Secundarios de Mongo atascados en el estado de inicio

tag-icon • tag-icon replication mongodb database-replication
Secundarios de Mongo atascados en el estado de inicio

Tengo una réplica de MongoDB configurada con secundarios que no pasarán del estado de INICIO. La base de datos es grande, pero ya deberían haberse trasladado a STARTUP2. Los puertos correctos están abiertos ya que puedo conectarme a los secundarios desde el primario y viceversa.

Respuesta1

Los siguientes pasos resolvieron el problema similar:

  1. Sobre el miembro PRIMARIO:

    rs.status()
{
"set" : "ShardD",
"date" : ISODate("2015-08-28T17:01:40.647Z"),
"myState" : 1,
"members" : [
        {
                "_id" : 0,
                "name" : "host.example.com:27017",
                "health" : 1,
                "state" : 1,
                "stateStr" : "PRIMARY",
                "uptime" : 1167,
                "optime" : Timestamp(1440780623, 1),
                "optimeDate" : ISODate("2015-08-28T16:50:23Z"),
                "electionTime" : Timestamp(1440780252, 2),
                "electionDate" : ISODate("2015-08-28T16:44:12Z"),
                "configVersion" : 3,
                "self" : true
        },
        {
                "_id" : 1,
                "name" : "192.0.2.222:27017",
                "health" : 1,
                "state" : 0,
                "stateStr" : "STARTUP",
                "uptime" : 584,
                "optime" : Timestamp(0, 0),
                "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
                "lastHeartbeat" : ISODate("2015-08-28T17:01:40.601Z"),
                "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
                "pingMs" : 0,
                "configVersion" : -2
        },
        {
                "_id" : 2,
                "name" : "192.0.2.223:27017",
                "health" : 1,
                "state" : 0,
                "stateStr" : "STARTUP",
                "uptime" : 676,
                "lastHeartbeat" : ISODate("2015-08-28T17:01:40.643Z"),
                "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
                "pingMs" : 0,
                "configVersion" : -2
        }
],
"ok" : 1

    }

  2. Verifique el nombre del miembro PRIMARIO (generalmente es igual a "_id": 0)

  3. Si el nombre tiene formato de nombre de dominio, intente reescribir el nombre en la dirección IP.Cambiar nombres de host en un conjunto de réplicas:

    cfg = rs.conf()
cfg.members[0].host = "192.0.2.221"
rs.reconfig(cfg)

Después de que el conjunto de réplicas volviera a su estado normal.

PS host.example.com se resolvió en la dirección IP en todos los hosts.

Respuesta2

Requiere que tanto el principal resuelva el nombre de host en la IP del secundario como que el secundario resuelva el nombre de host del principal en una IP.

En mi caso, olvidé agregar el archivo de hosts para que el secundario resuelva el nombre de host del principal. Una vez que actualicé el archivo de hosts en el secundario, el estado del secundario pasó a STARTUP2 y luego a SECUNDARIO.

Respuesta3

Este problema ocurre cuando hay problemas de conectividad entre los hosts mongo.

Por ejemplo, si el primario puede conectarse a los secundarios, pero los secundarios no pueden conectarse al primario.

En este caso, el primario aceptará la configuración del conjunto de réplicas ya que puede conectarse a los secundarios; sin embargo, los secundarios no pueden sincronizarse con el primario ya que no hay conectividad del secundario al primario.

información relacionada