MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

So überprüfen Sie, ob die Sekundärseite jetzt synchronisiert ist oder nicht

Hinweis :Sehen Sie sich die Antwort an bereitgestellt von arcseldon für ein benutzerfreundliches Äquivalent.

Sie können die Ausgabe von rs.status() verwenden . Wenn Secondary synchronisiert ist und nicht mit slaveDelay erstellt wurde Option dann optime und optimeDate der sekundären sollte gleich oder nahe (wenn es laufende Operationen gibt) denen der primären sein. In diesem Fall stateStr sollte gleich SECONDARY sein . Wenn also sekundäre Dateien synchronisiert werden, sollten Sie eine Ausgabe ähnlich dieser sehen (ein Mitglied wurde aus Gründen der Übersichtlichkeit aus der Ausgabe entfernt):

 {
    "set" : "rs0",
    "date" : ISODate("2013-11-08T14:58:49Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "hostname:27001",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 155,
            "optime" : Timestamp(1383915748, 1),
            "optimeDate" : ISODate("2013-11-08T13:02:28Z"),
            "self" : true
        },

        {
            "_id" : 2,
            "name" : "hostname:27003",
            "health" : 0,
            "state" : 8,
            "stateStr" : "SECONDARY",
            "uptime" : 0,
            "optime" : Timestamp(1383915748, 1),
            "optimeDate" : ISODate("2013-11-08T13:02:28Z"),
            "lastHeartbeat" : ISODate("2013-11-08T14:58:48Z"),
            "lastHeartbeatRecv" : ISODate("2013-11-08T14:58:42Z"),
            "pingMs" : 0,
            "syncingTo" : "hostname:27001"
        }
    ],
    "ok" : 1
}

Hier haben Sie die Ausgabe von rs.status() für denselben Replikatsatz, wenn einer der sekundären nicht synchronisiert ist. Zuerst sehen Sie diese optime und optimeDate für hostname:27003 unterscheidet sich von Primary, stateStr wird auf RECOVERING gesetzt und es gibt eine entsprechende lastHeartbeatMessage .

{
    "set" : "rs0",
    "date" : ISODate("2013-11-08T15:01:34Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "hostname:27001",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 320,
            "optime" : Timestamp(1383922858, 767),
            "optimeDate" : ISODate("2013-11-08T15:00:58Z"),
            "self" : true
        },

        {
            "_id" : 2,
            "name" : "hostname:27003",
            "health" : 1,
            "state" : 3,
            "stateStr" : "RECOVERING",
            "uptime" : 14,
            "optime" : Timestamp(1383915748, 1),
            "optimeDate" : ISODate("2013-11-08T13:02:28Z"),
            "lastHeartbeat" : ISODate("2013-11-08T15:01:34Z"),
            "lastHeartbeatRecv" : ISODate("2013-11-08T15:01:34Z"),
            "pingMs" : 0,
            "lastHeartbeatMessage" : "still syncing, not yet to minValid optime 527cfc90:19c4",
            "syncingTo" : "hostname:27001"
        }
    ],
    "ok" : 1
}

Wenn Secondary mit slaveDelay erstellt wurde dann optime und optimeDate kann anders sein als stateStr und lastHeartbeatMessage zeigt an, ob es Verzögerungen gibt.