mongodb - replica - Cómo comprobar secundaria está sincronizada ahora o no

sharding mongodb

Question

Hay la réplica con tres miembros (primario, secundario, secundario). Supongamos que uno de los secundarios está inactivo durante un día, después de volver a la réplica secundaria, ¿cómo puedo encontrarlo, está sincronizado o no?

Hice eso en un entorno de prueba, pero no pude encontrar datos útiles de rs.status() y db.printReplicationInfo() .

hay "longitud de registro de principio a fin" en db.printReplicationInfo() . pero es un gran momento por defecto y crece cuando el secundario está inactivo.

Answer 1

Escribí un pequeño script para el shell mongoDB. Muestra una diferencia entre el tiempo de operación y la hora de apertura. Puede usarlo en lugar de comparar manualmente los miembros del conjunto de réplicas

var isMaster = rs.isMaster();
var me = isMaster.me;

if(!isMaster.ismaster && isMaster.secondary)
{
    var status = rs.status();
    var master = isMaster.primary;

    var masterOptime = 0;
    var masterOptimeDate = 0;
    var myOptime = 0;
    var myOptimeDate = 0;

    for(var i = 0 ; i < status.members.length ; i++)
    {
        var member = status.members[i];
        if(member.name == me)
        {
            if(member.stateStr == "SECONDARY") {
                myOptime = member.optime.getTime();
                myOptimeDate = member.optimeDate.getTime();
            }
            else
            {
                print(me + '' is out of sync '' + member.stateStr);
                break;
            }
        }
        else if(member.name == master)
        {
            masterOptime = member.optime.getTime();
            masterOptimeDate = member.optimeDate.getTime();
        }

    }

    if(myOptime && myOptimeDate)
    {
        var optimeDiff = masterOptime - myOptime;
        var optimeDateDiff = masterOptimeDate - myOptimeDate;

        print(''optime diff: '' + optimeDiff);
        print(''optimeDate diff: '' + optimeDateDiff);
    }

}
else
{
    print(me + '' is not secondary'');
}

Answer 2

Actualización 13 de febrero de 2017

De acuerdo con la respuesta aceptada, rs.status() ofrece información adecuada y es un comando fácil de recordar. Sin embargo, ( utilizando personalmente Mongo 3 ahora), también me gusta mucho la comodidad y la legibilidad de rs.printSlaveReplicationInfo() .

Da una salida algo como:

rs.printSlaveReplicationInfo()

source: node-2:27017
    syncedTo: Mon Feb 13 2017 06:15:17 GMT-0500 (EST)
    0 secs (0 hrs) behind the primary
source: node-3:27017
    syncedTo: Mon Feb 13 2017 06:15:16 GMT-0500 (EST)
    1 secs (0 hrs) behind the primary

Como puede ver, es fácil tener una idea de si la sincronización entre los nodos en el conjunto de réplicas es correcta o no.

Answer 3

Nota : Asegúrese de verificar la respuesta proporcionada por arcseldon para obtener un equivalente fácil de usar.

Puede utilizar la salida de rs.status() . Si se sincroniza la secundaria y no se creó con la opción de slaveDelay , entonces el optimeDate de optimeDate y la optimeDate y optimeDate de la secundaria deben ser iguales o cercanas (si hay operaciones actuales) a las de la primaria. En ese caso, stateStr debe ser igual a SECONDARY . Por lo tanto, si se sincroniza la secundaria, debería ver una salida similar a esta (se ha eliminado un miembro de la salida para mayor claridad):

 {
    "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
}

Aquí tiene la salida de rs.status() para el mismo conjunto de réplicas si uno de los secundarios no está sincronizado. En primer lugar, verá que optime y optimeDate para el hostname:27003 de hostname:27003 difiere de primario, stateStr está configurado en RECOVERING y hay el 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
}

Si se ha creado secundario con slaveDelay entonces optime y optimeDate pueden ser diferentes, pero stateStr y lastHeartbeatMessage indicarán si hay algún retraso.