Вторичные серверы MongoDB не догоняют

У меня есть набор реплик, который я пытаюсь обновить до основного с большим объемом памяти и увеличенным дисковым пространством. Поэтому я совершил набег на пару дисков на новом первичном сервере, синхронизировал данные с вторичного и добавил их в набор реплик. Проверив rs.status (), я заметил, что все вторичные серверы отстают примерно на 12 часов от первичного. Поэтому, когда я пытаюсь принудительно установить новый сервер на основное место, это не сработает, потому что он устарел.

Это кажется большой проблемой, потому что в случае отказа основного мы отстаем как минимум на 12 часов, а некоторые почти на 48 часов.

Все оплоги перекрываются, а размер оплогов довольно велик. Единственное, что я могу понять, это то, что я выполняю много операций записи / чтения на первичном сервере, что может держать сервер в блокировке, не позволяя должным образом наверстать упущенное.

Есть ли способ заставить вторичную часть догнать первичную?

В настоящее время существует 5 серверов, последние 2 которых должны заменить 2 других узла. Узел с _id равным 6 должен быть тем, который заменит основной. Узел, наиболее удаленный от основного рабочего времени, отстает чуть более чем на 48 часов.

{
"set" : "gryffindor",
"date" : ISODate("2011-05-12T19:34:57Z"),
"myState" : 2,
"members" : [
    {
        "_id" : 1,
        "name" : "10******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 20231,
        "optime" : {
            "t" : 1305057514000,
            "i" : 31
        },
        "optimeDate" : ISODate("2011-05-10T19:58:34Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 2,
        "name" : "10******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 20231,
        "optime" : {
            "t" : 1305056009000,
            "i" : 400
        },
        "optimeDate" : ISODate("2011-05-10T19:33:29Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 3,
        "name" : "10******:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 20229,
        "optime" : {
            "t" : 1305228858000,
            "i" : 422
        },
        "optimeDate" : ISODate("2011-05-12T19:34:18Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 5,
        "name" : "10*******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 20231,
        "optime" : {
            "t" : 1305058009000,
            "i" : 226
        },
        "optimeDate" : ISODate("2011-05-10T20:06:49Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 6,
        "name" : "10*******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "optime" : {
            "t" : 1305050495000,
            "i" : 384
        },
        "optimeDate" : ISODate("2011-05-10T18:01:35Z"),
        "self" : true
    }
],
"ok" : 1
}