Início / dba / Perguntas / 74929
Accepted
Antonios
Asked: 2014-08-27 00:01:39 +0800 CST

Alertas falsos de replicação atrasada e atrasos na migração

  • 772

Estou executando o mongo 2.6.1 em um cluster de 3 estilhaços.

A configuração é: 3 nós de dados e 2 árbitros.

O único nó de dados é ocultado e atrasado por 3 horas (slavedelay).

Ocultei o nó para iniciar/parar durante o backup e o atraso de 3 horas é para segurança durante novas implantações.

O problema que estou enfrentando é: durante o fim de semana não há operações de gravação no cluster (essa é a natureza do aplicativo). Na manhã de segunda-feira, quando as gravações começam, o sistema de monitoramento informa que o nó de dados atrasado está atrasado há mais de 40 horas.

Eu acho que é porque o oplog que não tem registros durante o fim de semana e quando chega um registro na segunda-feira, precisa de 3 horas para chegar ao escravo atrasado.

Por favor, compartilhe sua opinião sobre o assunto, meus pensamentos estão corretos aqui ou devo verificar em uma direção diferente?

mongodb

1 respostas

  1. Best Answer

    Pelo que entendi, o secundário oculto sempre estará atrasado pelo número de segundos definido pelo slaveDelay. No seu caso, a qualquer momento do dia, o secundário oculto estará sempre atrasado em três horas desde a última gravação no oplog. Se não houver mais atividade de gravação, o secundário oculto será totalmente recuperado em três horas. Você pode verificar o status da replicação no Mongo diretamente conectando-se a cada nó e executando rs.printReplicationInfo()

    Eu configurei um cluster de 3 fragmentos usando um secundário oculto que está exatamente 180 segundos atrás, usando 2.6.3

    Aqui está a configuração dos dois secundários, o último está oculto e 180 segundos atrás.

    {
        "_id" : 1,
        "host" : "myhost:27001"
},
{
        "_id" : 2,
        "host" : "myhost:27002",
        "priority" : 0,
        "slaveDelay" : 180,
        "hidden" : true
},

    A prioridade é definida como 0 para impedir que o secundário oculto participe das eleições.

    Comecei a inserir documentos no shard e agora estou olhando para o oplog usando db.printReplicationInfo().

    Documentação do MongoDB sobre db.printReplicationInfo()

    Se executado em um secundário, o método chama db.printSlaveReplicationInfo(). Veja db.printSlaveReplicationInfo()

    Mongo secundário visível --porta 27001

    shard2:SECONDARY> db.printReplicationInfo()
configured oplog size:   50MB
log length start to end: 592secs (0.16hrs)
oplog first event time:  Tue Aug 26 2014 08:46:45 GMT+0000 (UTC)
oplog last event time:   Tue Aug 26 2014 08:56:37 GMT+0000 (UTC)
now:                     Tue Aug 26 2014 08:58:45 GMT+0000 (UTC)

    Secundário oculto mongo --port 27002

    shard2:SECONDARY> db.printReplicationInfo()
configured oplog size:   50MB
log length start to end: 722secs (0.2hrs)
oplog first event time:  Tue Aug 26 2014 08:43:46 GMT+0000 (UTC)
oplog last event time:   Tue Aug 26 2014 08:55:48 GMT+0000 (UTC)
now:                     Tue Aug 26 2014 08:58:48 GMT+0000 (UTC)

    180 segundos depois, o secundário oculto alcança mongo --port 27002

    shard2:SECONDARY> db.printReplicationInfo()
configured oplog size:   50MB
log length start to end: 592secs (0.16hrs)
oplog first event time:  Tue Aug 26 2014 08:46:45 GMT+0000 (UTC)
oplog last event time:   Tue Aug 26 2014 08:56:37 GMT+0000 (UTC)
now:                     Tue Aug 26 2014 09:02:18 GMT+0000 (UTC)

    Portanto, esteja você gravando no oplog ou não, o secundário continuará a acompanhar por N segundos, conforme definido em slaveDelay. Se a sua ferramenta de monitoramento estiver indicando 40 horas, verifique primeiro se você está obtendo as mesmas informações usando os comandos do replicationInfo do mongo.

    db.getReplicationInfo()

    db.printReplicationInfo()

    rs.printReplicationInfo()

    A saída de db.printReplicationInfo() é idêntica à de rs.printReplicationInfo()

    Atualizar

    http://docs.mongodb.org/manual/core/replica-set-delayed-member/

    Com relação à sua pergunta sobre migrações de blocos atrasadas

    Fragmentação

    Em clusters fragmentados, os membros atrasados ​​têm utilidade limitada quando o balanceador está ativado. Como os membros atrasados ​​replicam as migrações de partes com atraso, o estado dos membros atrasados ​​em um cluster fragmentado não é útil para recuperar um estado anterior do cluster fragmentado se ocorrer alguma migração durante a janela de atraso.

    Se eu entendi seu comentário corretamente.

    Se secondThrottle fosse definido como false , o balanceador poderia continuar a migrar blocos sem esperar por um membro atrasado. Não tenho certeza se isso é 100% preciso, mas foi assim que interpretei a documentação deles sobre secundárioThrottle e membros atrasados.

    • 2

relate perguntas