Secondaries do MongoDB não atualizando

Question

Eu tenho um conjunto de réplicas que estou tentando atualizar o primário para um com mais memória e espaço em disco atualizado. Então eu invadi alguns discos juntos no novo primário, rincronizei os dados de um secundário e os adicionei ao conjunto de réplicas. Depois de verificar o rs.status (), notei que todos os secundários estão cerca de 12 horas atrás do primário. Então, quando tento forçar o novo servidor para o ponto principal, ele não funciona, porque não está atualizado.

Isto parece ser um grande problema, porque no caso de o primário falhar, temos pelo menos 12 horas e algumas quase 48 horas atrasadas.

Os oplogs se sobrepõem e o oplogsize é razoavelmente grande. A única coisa que posso imaginar é que estou realizando muitas gravações / leituras no primário, o que poderia manter o servidor bloqueado, não permitindo uma recuperação adequada.

Existe uma maneira de forçar um secundário a alcançar o primário?

Existem atualmente 5 Servidores com os últimos 2 para substituir 2 dos outros nós. O nó com _id as 6, é o único a substituir o primário. O nó que está mais distante da optime principal está um pouco acima de 48 horas.

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

    

Answer 1

Depois de examinar tudo, vi um único erro, o que me levou de volta a uma mapreduce que foi executada no primário, que tinha esse problema: link . Assim, quando a replicação foi tentada, ela não conseguiu sincronizar devido a uma operação defeituosa / corrompida no oplog.

    

Answer 2

Para responder a pergunta original (que não teria resolvido o problema do OP), acredito que a melhor maneira de forçar um secundário a "recuperar o atraso" seria removê-lo do conjunto e adicioná-lo novamente, mas as chances são (como neste caso), existem outros problemas. Verifique seus registros.