O problema (provavelmente)
A última operação no primário é de "2015-05-15T02:10:56Z", enquanto a última operação do secundário é de "2015-05-14T11:23:51Z", que é uma diferença de aproximadamente 15 horas. Essa janela pode exceder sua janela de oplog de replicação (a diferença entre a hora da primeira e da última entrada de operação em seu oplog). Simplificando, há muitas operações no primário para o secundário acompanhar.
Um pouco mais elaborado (embora simplificado):durante uma sincronização inicial, os dados do secundário são os dados de um determinado ponto no tempo. Quando os dados desse ponto no tempo são sincronizados, o secundário se conecta ao oplog e aplica as alterações que foram feitas entre o referido ponto no tempo e agora de acordo com as entradas do oplog. Isso funciona bem desde que o oplog mantenha todas as operações entre o ponto mencionado no tempo. Mas o oplog tem um tamanho limitado (é uma chamada coleção limitada ). Portanto, se houver mais operações acontecendo no primário do que o oplog pode conter durante a sincronização inicial, as operações mais antigas "desaparecem". O secundário reconhece que nem todas as operações necessárias para "construir" os mesmos dados do primário estão disponíveis e se recusa a concluir a sincronização, ficando em
RECOVERY modo. As soluções
O problema é conhecido e não um bug, mas resultado do funcionamento interno do MongoDB e várias suposições à prova de falhas feitas pela equipe de desenvolvimento. Portanto, existem várias maneiras de lidar com a situação. Infelizmente, como você tem apenas dois nós de rolamento de dados, todos envolvem tempo de inatividade.
Opção 1:aumentar o tamanho do oplog
Este é o meu método preferido, pois lida com o problema de uma vez por todas. É um pouco mais complicado do que outras soluções, no entanto. De uma perspectiva de alto nível, estes são os passos que você toma.
- Encerrar o primário
- Crie um backup do oplog usando acesso direto aos arquivos de dados
- Reinicie o
mongodno modo autônomo - Copiar o oplog atual para uma coleção temporária
- Excluir o oplog atual
- Recrie o oplog com o tamanho desejado
- Copie de volta as entradas do oplog da coleção temporária para o novo e brilhante oplog
- Reiniciar
mongodcomo parte do conjunto de réplicas
Não se esqueça de aumentar o oplog do secundário antes de fazer a sincronização inicial, pois ele pode se tornar o primário em algum momento no futuro!
Para obter detalhes, leia "Alterar o tamanho do oplog" nos tutoriais sobre manutenção do conjunto de réplicas .
Opção 2:desligue o aplicativo durante a sincronização
Se a opção 1 não for viável, a única outra solução real é desligar o aplicativo causando carga no conjunto de réplicas, reiniciar a sincronização e esperar que ela seja concluída demais. Dependendo da quantidade de dados a serem transferidos, calcule com várias horas.
Uma nota pessoal
O problema da janela de oplog é bem conhecido. Embora conjuntos de réplicas e clusters fragmentados sejam fáceis de configurar com o MongoDB, é necessário algum conhecimento e um pouco de experiência para mantê-los adequadamente. Não execute algo tão importante quanto um banco de dados com uma configuração complexa sem conhecer o básico - caso algo ruim (tm) aconteça, isso pode levar a uma situação FUBAR.
