☰

Mongo-Sekundärelemente bleiben im Startzustand hängen

tag-icon • tag-icon replication mongodb database-replication
Mongo-Sekundärelemente bleiben im Startzustand hängen

Ich habe einen MongoDB-Replikatsatz mit Sekundärservern, die den Status STARTUP nicht überstehen. Die Datenbank ist groß, aber sie sollten inzwischen zu STARTUP2 verschoben worden sein. Die richtigen Ports sind geöffnet, da ich vom Primärserver aus eine Verbindung zu den Sekundärservern herstellen kann und umgekehrt.

Antwort1

Die nächsten Schritte lösten das ähnliche Problem:

  1. Auf dem PRIMARY-Mitglied:

    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. Überprüfen Sie den Namen des PRIMARY-Mitglieds (normalerweise ist er gleich „_id“: 0).

  3. Wenn der Name die Form eines Domänennamens hat, versuchen Sie, den Namen in eine IP-Adresse umzuschreiben.Hostnamen in einem Replikationssatz ändern:

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

Danach wurde der Replikationssatz in den Normalzustand zurückversetzt.

PS: host.example.com wurde auf allen Hosts in eine IP-Adresse aufgelöst.

Antwort2

Dies erfordert, dass sowohl der primäre Server den Hostnamen in die IP des sekundären Servers auflöst als auch der sekundäre Server den Hostnamen des primären Servers in eine IP auflöst.

In meinem Fall habe ich vergessen, die Hosts-Datei für den sekundären Server hinzuzufügen, um den Hostnamen des primären Servers aufzulösen. Nachdem ich die Hosts-Datei im sekundären Server aktualisiert hatte, wechselte der Status des sekundären Servers zu STARTUP2 und dann zu SECONDARY.

Antwort3

Dieses Problem tritt auf, wenn es Verbindungsprobleme zwischen Mongo-Hosts gibt.

Beispielsweise kann sich das Primärgerät mit dem Sekundärgerät verbinden, das Sekundärgerät jedoch nicht mit dem Primärgerät.

In diesem Fall akzeptiert das Primärsystem die Konfiguration des Replikatsatzes, da es eine Verbindung zu den Sekundärsystemen herstellen kann. Die Sekundärsysteme können jedoch nicht mit dem Primärsystem synchronisiert werden, da keine Verbindung vom Sekundärsystem zum Primärsystem besteht.

verwandte Informationen