Conjunto de réplica do MongoDB com atraso de replicação somente em um nó

Question

vivenciamos um comportamento estranho em nosso Conjunto de Réplicas do MongoDB, configuração de 3 Nós (todas as CPUs Xeon Quad-Core-Class, 16 GB de RAM para um, 24 GB para os outros dois nós) O único nó com menos RAM é secundário normal com prioridade 0, outros dois prioridade 1. Recentemente, ocorreu um atraso de replicação de cerca de 60 segundos a cada 3 a 4 horas, desaparecendo após 2-3 minutos (verificações do Nagios!)

Quase não temos tráfego nessas máquinas, apenas alguns bancos de dados com um tamanho de 0,3 GB e um é de 5 GB. E nós temos uma coleção que tem cerca de 65.000 entradas, mas também um índice id .

O mais estranho é que o secundário de 16gb não tem atraso, mas apenas o secundário das duas máquinas maiores. Eu apenas mudei para ser primário para ver se o antigo primário (agora secundário) também tem esse comportamento.

Alguém sabe o que podemos fazer ou verificar? Porque não temos ideia.

Eu verifiquei a carga e os processos dessas máquinas, a conectividade e o roteamento da rede, os estados do disco - tudo bem.

    

Answer 1

Algumas verificações rápidas:

• Você está executando no 2.0 ou abaixo? A replicação recebeu uma grande reformulação em 2.2
• Você tem alguma coleção limitada? Um índice ausente em _id em uma coleção limitada pode causar esse tipo de atraso
• Você menciona que os hosts não estão muito ocupados - se você tiver lacunas em seus novos ops, a matemática usada para calcular o atraso pode relatar falsamente quando não houver operações
• Como você está calculando o atraso? Eu definitivamente tentaria confirmar qualquer atraso do shell - a última oportunidade das entradas em rs.status() seria um bom começo
• Verificar duplamente o lado da rede, picos de latência e / ou perda intermitente de pacotes podem causar isso e ser temporário o suficiente para ser difícil de detectar (veja netstat --statistics antes e depois de um pico de atraso, por exemplo - veja se retransmissões ou erorrs estão aumentando)
• Se você estiver executando o 2.2, veja se está trocando o host, o secundário atrasado está sendo sincronizado, revelado de forma um tanto confusa pelo campo [syncingTo][3] em rs.status() . Isso é feito com o comando rs.syncFrom() .
• Se ainda não estiver disponível, coloque o conjunto em MMS e veja se algo está aumentando / quase ao mesmo tempo o pico de atraso para apontar na direção certa.

Se, depois de tudo isso, você ainda não sabe o que está causando isso, então pode estar além de responder no serverfault de uma maneira razoável (precisaria ver logs, estatísticas etc.) - Eu recomendaria o mongodb usuário do grupo do Google como a próxima etapa.