mongodb mantém o loop ao tentar sincronizar dados

Question

Estou convertendo meu myongodb autônomo em um conjunto de réplicas. Eu adicionei mais um membro (e eu quero adicionar mais dois membros depois, e desligar o servidor primário).

Meu mongodb principal está executando o 2.2.3, e o novo membro da réplica executando a versão mais recente do mongodb, 2.6.4.

Ambos os bancos de dados estão sendo executados no servidor Ubuntu 14.04, no microsoft Azure e estão sendo executados no mesmo grupo de afinidade. (O tamanho de Vm é A2)

Eu editei o ulimit de "nofile" e "nproc" para 65535, Depois de ver o conselho de monitoramento do MMMS, BU somente nos secundários, para evitar o tempo de reinicialização das máquinas, É necessário?

Cheguei em algum lugar acima do documento de 80m no banco de dados principal e está sendo executado em produção ao vivo. é por causa disso?

Após algumas horas de sincronização de dados, o TTL mostrou os seguintes erros e começou a sincronizar novamente. e continua em loop.

[rsSync] done building bottom layer, going to commit

[rsSync] old journal file will be removed: /datadrive/data/journal/j._9

[rsSync] build index done. scanned 55381316 total records. 1348.97 secs

[conn221] serverStatus was very slow: { after basic: 0, after asserts: 0, after backgroundFlushing: 0, after connections: 0, after cursors: 0, after dur: 0, after extra_info: 0, after globalLock: 0, after indexCounters: 0, after locks: 0, after network: 0, after opcounters: 0, after opcountersRepl: 0, after recordStats: 744214, after repl: 744214, at end: 744214 }

[conn221] command admin.$cmd command: serverStatus { serverStatus: 1 } keyUpdates:0 numYields:0 locks(micros) r:31 reslen:3920 1243515ms

[conn228] serverStatus was very slow: { after basic: 0, after asserts: 0, after backgroundFlushing: 0, after connections: 0, after cursors: 0, after dur: 0, after extra_info: 0, after globalLock: 0, after indexCounters: 0, after locks: 0, after network: 0, after opcounters: 0, after opcountersRepl: 0, after recordStats: 634932, after repl: 634932, at end: 634932 }

[conn228] command admin.$cmd command: serverStatus { serverStatus: 1 } keyUpdates:0 numYields:0 locks(micros) r:33 reslen:3920 1073310ms

[conn235] serverStatus was very slow: { after basic: 0, after asserts: 0, after backgroundFlushing: 0, after connections: 0, after cursors: 0, after dur: 0, after extra_info: 0, after globalLock: 0, after indexCounters: 0, after locks: 0, after network: 0, after opcounters: 0, after opcountersRepl: 0, after recordStats: 578551, after repl: 578551, at end: 578551 }

[conn235] command admin.$cmd command: serverStatus { serverStatus: 1 } keyUpdates:0 numYields:0 locks(micros) r:28 reslen:3920 963376ms

[conn194] SocketException handling request, closing client connection: 9001 socket exception [SEND_ERROR] server [ServerIp:1250]

[conn252] SocketException handling request, closing client connection: 9001 socket exception [SEND_ERROR] server [ServerIp:1248]

[rsSync] Socket say send() errno:110 Connection timed out ServerIp:27017

[rsSync] replSet initial sync exception: 9001 socket exception [SEND_ERROR] server [Serverip:27017] 8 attempts remaining

[rsSync] replSet initial sync pending

[rsSync] replSet syncing to: [ServerAddress]:27017

[rsSync] replSet initial sync drop all databases

[rsSync] dropAllDatabasesExceptLocal 2

[rsSync] removeJournalFiles

[rsSync] replSet initial sync clone all databases

[rsSync] replSet initial sync cloning db: PkgsKeyValues

[FileAllocator] allocating new datafile /datadrive/data/PkgsKeyValues.ns, filling with zeroes...

[FileAllocator] allocating new datafile /datadrive/data/PkgsKeyValues.3, filling with zeroes...

[FileAllocator] done allocating datafile /datadrive/data/PkgsKeyValues.3, size: 512MB, took 0.124 secs

Alguma idéia?

    

Answer 1

É difícil dizer com certeza baseado em informações tão limitadas, mas parece que algo está matando a conexão entre o secundário e o primário enquanto ele está tentando sincronizar. Se está acontecendo repetidamente aproximadamente ao mesmo tempo, então sugere que algo em sua rede esteja impondo um tempo máximo de conexão. Se isso está acontecendo aleatoriamente, sugere-se que há algo estranho na própria rede (impossível dizer o que poderia ser sem uma solução de problemas significativa).

Também é óbvio, a partir do snippet de logs, que o secundário está sob carga pesada quando isso acontece, pois é necessário várias horas para executar o ServerStatus (normalmente, sub 100ms quando não está sob carga) - agora ele está criando um índice no momento , que é uma operação de bloqueio, de modo que pode ser um arenque vermelho, se esse for um índice grande. Se isso não é um índice grande, então sugere que o secundário está um pouco abaixo do provisionado em termos de recursos.

Se você não conseguir resolver o loop, você pode tomar outras medidas para colocar o secundário em funcionamento como copiando os arquivos de dados , no entanto, a menos que você tenha opções de snapshot que envolvam interromper gravações ou reduzir o tempo de duração da cópia.