Por que o Mongo está preso no STARTUP2?

12

Eu tenho uma Mongoréplica definida com alguns secundários. Uma caixa que hospeda uma instância secundária caiu e perdeu o banco de dados.

Iniciei a Mongoinstância secundária novamente e agora ela fica presa no STARTUP2 por mais de 12 horas. Isso faz sentido ? Os documentos dizem que Mongodevem estar em STARTUP2 por um curto período de tempo antes de entrar no estado RECOVERING

O que significa exatamente o STARTUP2? Está copiando o banco de dados do primário? Como posso verificá-lo (assumindo que o Mongo esteja sendo executado no Linux)?

mongodb recovery

— Michael
fonte

11

A resposta do eoinbrazil está parcialmente incorreta. Um novo nó pode ficar em STARTUP2 por um longo tempo. O link postado diz:

Cada membro de um conjunto de réplicas entra no estado STARTUP2 assim que o mongod termina de carregar a configuração desse membro, quando é um membro ativo do conjunto de réplicas. O membro decide se deve ou não realizar uma sincronização inicial. Se um membro iniciar uma sincronização inicial, ele permanecerá em STARTUP2 até que todos os dados sejam copiados e todos os índices criados. Depois, o membro faz a transição para RECUPERAÇÃO.

Estou administrando uma coleção de 700 GB e, quando adiciono um novo nó, o estado STARTUP2 permanece bem mais de 24 horas. Mas você ainda pode ver se algo está acontecendo, observando se o banco de dados cresce. Você pode ver o tamanho do banco de dados no novo nó com

show databases

ou você também pode observar o diretório de dados para ver se ele ainda está crescendo. (no linux com os comandos ls, df, du, iotop, etc ....)

— Kenyakorn Ketsombut
fonte

1

show databasesfalha comnot master and slaveOk=false

— JDPeckham

Observando os logs, você pode ver o progresso. Por exemplo, ele mostrará algo como: [rsSync] Compilação de índice: 2538000/22982417 11%

— Daniel Benedykt

4

O estado STARTUP2 significa que o nó não pode votar. Um membro de um RS entra nesse estado quando o processo do MongoD termina de carregar sua configuração. Nesse estado, o membro criou threads para lidar com as operações de replicação interna, mas ainda precisa mudar de estado para Recuperando e daí para a Secundária (consulte o [estado e seus detalhes nos documentos]) .

Se o seu nó estiver nesse estado há mais de um breve período, você estará encontrando algum comportamento estranho. É praticamente impossível analisar sem os logs para determinar por que está bloqueado. A execução de rs.status () e db.printSlaveReplicationInfo () fornecerá alguns detalhes sobre a imagem local no nó.

A abordagem normal para resolver isso seria encerrar o nó, limpar seus arquivos de dados (esses arquivos no dbpath) e reiniciá-lo. Isso reiniciará o processo de sincronização inicial e deverá passar para SECONDARY. Se ele travar no STARTUP2 novamente, será necessário examinar os logs para reunir mais informações sobre o motivo - há várias causas, mas uma que pode acontecer é uma rede inadequada ou alguma contenção de recursos locais.

Um ponto a ser observado é que, enquanto uma sincronização inicial estiver em andamento, o nó permanecerá em STARTUP2; portanto, dependendo da quantidade de dados sincronizados, isso pode levar uma quantidade considerável de tempo (potencialmente dias).

— eoinbrazil
fonte

Obrigado. Removemos os dados e reiniciamos o Mongo. Ainda está em STARTUP2. Parece que o Mongo está funcionando. Está consumindo CPU e, como vejo no db.statsbanco de dados, está crescendo. O log diz que alguns objetos cloned. Ainda estou procurando possíveis causas para esse problema.

— Michael

1

Se isso ainda for um problema, convém fazer uma cópia de outro nó (consulte este procedimento - docs.mongodb.org/manual/tutorial/resync-replica-set-member/… ). Se você pode anexar os destaques e detalhes dos logs em qual versão está usando, isso pode apontar para uma causa, mas igualmente esse é um comportamento incomum. Você tentou fazer ping entre os nós para ver como é a latência da rede?

— Eoinbrazil 12/02

O Mongo 2.4.6 pingentre os hosts está OK.

— Michael

Como são os tempos de ping, pois podem ser problemas de rede intermitentes? Nesse caso, é muito mais fácil se você puder adicionar algumas das saídas de log, pois esse é um comportamento não padrão e os logs são a principal fonte de verdade ao tentar determinar exatamente o que está ocorrendo.

— Eoinbrazil

Receio não poder mostrar os logs aqui. No entanto, notei que ele tenta se conectar a outro membro secundário, que está inoperante. Pode ser a causa do problema?

— Michael

1

Uma causa possível é que seu secundário se torne "obsoleto", conforme indicado aqui .

Ao ressincronizar um membro, verifique se o RS não está sob carga pesada.

— user2829759
fonte

0

O estado STARTUP2 pode ser devido ao espaço insuficiente no disco. Bem, como não há onde sincronizar, ele pode permanecer apenas no estado @ STARTUP2.

— Aesop Lee
fonte