Как проверить вторичную синхронизацию сейчас или нет

существует реплика с тремя членами (первичная, вторичная, вторичная). Предположим, что один из второстепенных пользователей в течение дня, после возвращения вторичный назад к реплике, как я могу найти, синхронизирован или нет?

Я сделал это в тестовой среде, но не смог найти полезные данные из rs.status() и db.printReplicationInfo().

в db.printReplicationInfo() есть "длина записи до конца". но это большое время по умолчанию и растет, когда вторичный снижается.

Ответ 1

Примечание. Обязательно проверьте ответ, предоставленный arcseldon для дружественного пользователя.

Вы можете использовать вывод rs.status(). Если вторичная синхронизация и не была создана с опцией slaveDelay, тогда optime и optimeDate вторичного значения должны быть равны или близки (если есть текущие операции) к параметрам primary. В этом случае stateStr должен быть равен SECONDARY. Поэтому, если вторичный синхронизирован, вы должны увидеть аналогичный ему результат (один элемент был удален из вывода для ясности):

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

Здесь вы выводите rs.status() для того же набора реплик, если один из второстепенных не синхронизирован. Прежде всего, вы увидите, что optime и optimeDate для hostname:27003 отличается от primary, stateStr устанавливается на RECOVERING и существует соответствующий 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
}

Если вторичное было создано с помощью slaveDelay, тогда optime и optimeDate могут быть разными, но stateStr и lastHeartbeatMessage укажут, есть ли какое-то отставание.

Ответ 2

Обновление 13 февраля 2017 года

Согласитесь с принятым ответом, что rs.status() предлагает адекватную информацию и является легкой командой для запоминания. Однако (лично с использованием Mongo 3), также очень нравится удобство и удобочитаемость rs.printSlaveReplicationInfo().

Он выводит что-то вроде:

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

Как вы можете видеть, легко понять, является ли синхронизация между узлами в наборе реплик здоровой или нет.

Ответ 3

Я написал немного script для оболочки mongoDB. Он показывает разницу между optime и optimeDate. Вы можете использовать его вместо сравнения элементов набора реплик вручную.

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');
}