Réplica do Mongo DB configurada Preso no estado RECUPERAÇÃO

Criamos um conjunto de réplicas e agora o problema é que 2 membros do conjunto de réplicas [3 membros] estão no modo de recuperação a partir de 48 horas. Inicialmente, o tamanho dos nós em recuperação estava aumentando e agora até isso parou. Portanto, na recuperação de nós, eles ficam presos após 90 GB de dados com mais de 60 GB de dados locais.

Como sair deste modo?

A maneira fácil, embora um pouco insegura

1. Pare o primeiro secundário
2. Exclua o conteúdo dele dbpath
3. Reinicie o secundário
4. Espere que ele atinja o primário
5. Repita o processo com o segundo secundário

Isso é um pouco inseguro, pois não se sabe por que os secundários entraram no estado de recuperação.

A maneira mais segura, mas também mais intrusiva

Como acima, mas pare seu aplicativo durante o processo. Isso evita a possibilidade de seu aplicativo estar inserindo mais dados do que os secundários são capazes de replicar. No entanto, o problema pode ocorrer durante a produção.

A maneira mais segura, mas também a mais intrusiva

1. Encerre todo o conjunto de réplicas
2. Remover o conteúdo de dbpathem ambos os secundários
3. Copie o conteúdo dbpathpara para os dois secundáriosdbpath
4. Inicie o primário primário.
5. Inicie um dos antigos secundários.
6. Aguarde até que uma nova primária seja eleita.
7. Inicie o secundário restante.

Algumas notas:

Use MMS . É gratuito, fácil de configurar e fornece boas informações sobre seu conjunto de réplicas. Tente manter o valor de "atraso na replicação" em torno de 0 e use todos os meios necessários para que o atraso na replicação nunca seja maior que a "janela do log de replicação".

Sempre verifique se você possui uma rede de 1 Gb e uma (desculpe) carga de RAM. Quanto mais melhor. Regra geral: mais da metade da RAM e dos SSDs do que o dobro da RAM e nenhum SSD (com a RAM permanecendo dentro de limites razoáveis).

Isenção de responsabilidade: sempre faça um backup dos dados de produção antes de brincar com eles.

O processo de replicação falha mesmo que você inicie o scratch a partir de um novo dbpath no secundário. Então, a coisa é fazer algumas alterações no oplog . O tamanho do oplog deve ser definido como um valor ideal para que ele possa manipular todas as gravações de aplicativos nele.

Aumentando o tamanho do oplog:

Encerrar o servidor principal

use admin

db.shutdownServer()

Comece o primário como autônomo e execute em uma porta diferente, digamos 37017

Entre no mongo na porta 37017

mongo --port 37017

Remova o conteúdo antigo no banco de dados local

Por segurança, tenha backop do antigo oplog antes de soltar

mongodump --db local --collection 'oplog.rs' --port 37017

Solte o conteúdo antigo no banco de dados local

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

A coleção de conjuntos de réplicas não pode ser descartada; portanto, remova-a com o ID necessário:

db.system.replset.remove({ "_id" : "your_replsetname"})

Crie um novo oplog do tamanho necessário, digamos 50 GB

db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )

Além disso, você pode especificar o tamanho do oplog em MB no arquivo mongod.conf, digamos 50 GB, 429496 MB

replication:
   oplogSizeMB: 429496

Espero que isto ajude !!!

Editar:

Como mencionado por Nicholas Tolley Cottrell nos comentários. No MongoDB versão 3.6 , podemos alterar o tamanho do oplog em tempo de execução sem reiniciar.

Verifique o tamanho atual do oplog

use local
db.oplog.rs.stats().maxSize

Para alterar o tamanho do oplog para 10 GB

db.adminCommand({replSetResizeOplog: 1, size: 10000})