Perché Mongo è bloccato in STARTUP2?

13

Ho una Mongoreplica impostata con alcuni secondari. Un box, che ospita un'istanza secondaria, si è bloccato e ha perso il database.

Ho Mongoriavviato l'istanza secondaria e ora è bloccato in STARTUP2 per più di 12 ore. Ha senso ? I documenti dicono che Mongodovrebbe essere in STARTUP2 per un breve periodo di tempo prima di entrare nello stato RECUPERARE

Cosa significa esattamente STARTUP2? Copia il database dal primario? Come posso verificarlo (supponendo che Mongo sia in esecuzione su Linux)?

mongodb recovery

— Michael
fonte

12

La risposta di eoinbrazil è in parte errata. Un nuovo nodo può essere in STARTUP2 per molto tempo. Il link pubblicato indica:

Ogni membro di un set di repliche entra nello stato STARTUP2 non appena mongod termina il caricamento della configurazione di quel membro, a quel punto diventa un membro attivo del set di repliche. Il membro decide quindi se effettuare o meno una sincronizzazione iniziale. Se un membro avvia una sincronizzazione iniziale, il membro rimane in STARTUP2 fino a quando tutti i dati non vengono copiati e tutti gli indici vengono creati. Successivamente, il membro passa a RECOVERING.

Sto amministrando una raccolta da 700 GB e, quando aggiungo un nuovo nodo, lo stato di STARTUP2 rimane ben oltre 24 ore. Ma puoi ancora vedere se sta succedendo qualcosa, osservando se il database cresce. Puoi vedere la dimensione del database sul nuovo nodo con

show databases

oppure puoi anche osservare la directory dei dati, per vedere se è ancora in crescita. (su Linux con i comandi ls, df, du, iotop, ecc ....)

— Kenyakorn Ketsombut
fonte

1

show databasesfallisce connot master and slaveOk=false

— JDPeckham il

Guardando i registri è possibile vedere i progressi. Ad esempio mostrerà qualcosa di simile: [rsSync] Build indice: 2538000/22982417 11%

— Daniel Benedykt

4

Lo stato STARTUP2 indica che il nodo non può votare. Un membro di una RS entra in questo stato una volta che il processo MongoD ha completato il caricamento della sua configurazione. In questo stato, il membro ha creato thread per gestire le operazioni di replica interna ma deve ancora cambiare lo stato in Ripristino e in seguito da quello a Secondario (vedere lo stato e i relativi dettagli nei documenti) .

Se il tuo nodo è stato in questo stato per più di un breve periodo, stai riscontrando uno strano comportamento. Questo è praticamente impossibile da analizzare senza i registri per determinare perché è bloccato. L'esecuzione di rs.status () e db.printSlaveReplicationInfo () fornisce alcuni dettagli sull'immagine locale sul nodo.

L'approccio normale per risolvere questo sarebbe quello di arrestare il nodo, cancellare i suoi file di dati (quei file nel dbpath) e riavviarlo. Ciò riavvierà il processo di sincronizzazione iniziale e dovrebbe passare a SECONDARIO. Se si blocca nuovamente in STARTUP2, è necessario esaminare i registri per raccogliere ulteriori informazioni sul perché: esistono diverse cause, ma una che può accadere è una rete instabile o una contesa di risorse locali.

Un punto da notare è che mentre è in corso una sincronizzazione iniziale, il nodo rimarrà in STARTUP2, quindi, a seconda della quantità di dati sincronizzati, ciò potrebbe richiedere molto tempo (potenzialmente giorni).

— eoinbrazil
fonte

Grazie. Abbiamo rimosso i dati e riavviato Mongo. È ancora in STARTUP2. Sembra che il Mongo stia funzionando. Sta consumando CPU e come vedo nel db.statsdatabase sta crescendo. Il registro dice che alcuni oggetti cloned. Sto ancora cercando possibili cause di questo problema.

— Michael,

1

Se il problema persiste, potresti voler fare una copia da un altro nodo (vedi questa procedura - docs.mongodb.org/manual/tutorial/resync-replica-set-member/… ). Se è possibile allegare i punti salienti e i dettagli dei registri su quale versione si sta utilizzando, potrebbe indicare una causa, ma allo stesso modo si tratta di un comportamento insolito. Hai provato a eseguire il ping tra i nodi per vedere com'è la latenza della rete?

— eoinbrazil,

Mongo 2.4.6 pingtra gli host è ok.

— Michael,

Quali sono i tempi di ping in quanto potrebbero essere problemi di rete intermittenti? In questo caso, è molto più semplice aggiungere alcuni degli output dei log poiché si tratta di un comportamento non standard e i log sono la fonte principale di verità quando si cerca di determinare esattamente cosa sta accadendo.

— eoinbrazil,

Temo di non poter mostrare i log qui. Tuttavia ho notato che tenta di connettersi a un altro membro secondario, che è inattivo. Può essere la causa del problema?

— Michael,

1

Una possibile causa è che il tuo secondario diventa "stantio" come indicato qui .

Quando si risincronizza un membro, assicurarsi che RS non sia sotto carico pesante.

— user2829759
fonte

0

Lo stato di STARTUP2 potrebbe essere dovuto a spazio su disco insufficiente. Bene, poiché non esiste un punto di sincronizzazione, può rimanere solo nello stato @ STARTUP2.

— Esopo Lee
fonte