Set di repliche MongoDB SECONDARIO Bloccato nello stato `ROLLBACK`

Durante un recente aggiornamento automatico del nostro mongodb PRIMARY, quando è stato PRIMARYabbandonato, è entrato definitivamente in uno ROLLBACKstato.

Dopo diverse ore nello ROLLBACKstato, non c'era ancora nessun .bsonfile di rollback nella rollbackdirectory nella directory del database mongodb. Questo, e anche questa riga nel nostro file di registro:, [rsSync] replSet syncThread: 13410 replSet too much data to roll backsembra indicare che il ROLLBACKprocesso non è riuscito.

Vorrei un po 'di aiuto per analizzare cosa è andato storto.

• Sembra che si siano verificati due diversi rollback nei nostri registri. È questo il caso o è stato uno che ha richiesto 3 ore?
• Se il primo rollback (alle 19:00) ha avuto esito positivo, perché non è stato visualizzato nulla nella nostra rollbackdirectory?
• Qualche ipotesi sulla causa di tutti quegli avvertimenti? Potrebbe essere correlato al fallimento del rollback?
• Abbiamo perso 18 secondi di dati a causa del primo ROLLBACK?
• Esiste una soluzione generica al problema "bloccato nello ROLLBACKstato"? Alla fine abbiamo dovuto fare il tubo su tutto il nostro DB e risincronizzarci dal primario.

Le righe di registro pertinenti sono:

# Primary coming back after restart...
Tue May 15 19:01:01 [initandlisten] MongoDB starting : pid=3684 port=27017 dbpath=/var/lib/mongodb 64-bit host=magnesium
Tue May 15 19:01:01 [initandlisten] db version v2.0.5, pdfile version 4.5
# ... init stuff
Tue May 15 19:01:01 [initandlisten] journal dir=/var/lib/mongodb/journal
Tue May 15 19:01:01 [initandlisten] recover : no journal files present, no recovery needed
# ... More init stuff
Tue May 15 19:01:03 [rsStart] trying to contact rs1arb1.c9w.co:27017
Tue May 15 19:01:03 [rsStart] trying to contact rs1m2.c9w.co:27017
Tue May 15 19:01:03 [rsStart] replSet STARTUP2
Tue May 15 19:01:03 [rsHealthPoll] replSet member rs1arb1.c9w.co:27017 is up
Tue May 15 19:01:03 [rsHealthPoll] replSet member rs1arb1.c9w.co:27017 is now in state ARBITER
Tue May 15 19:01:03 [rsSync] replSet SECONDARY
Tue May 15 19:01:05 [rsHealthPoll] replSet member rs1m2.c9w.co:27017 is up
Tue May 15 19:01:05 [rsHealthPoll] replSet member rs1m2.c9w.co:27017 is now in state PRIMARY
Tue May 15 19:01:09 [rsSync] replSet syncing to: rs1m2.c9w.co:27017
Tue May 15 19:01:09 [rsSync] replSet our last op time written: May 15 19:00:51:6
Tue May 15 19:01:09 [rsSync] replSet rollback 0
Tue May 15 19:01:09 [rsSync] replSet ROLLBACK
Tue May 15 19:01:09 [rsSync] replSet rollback 1
Tue May 15 19:01:09 [rsSync] replSet rollback 2 FindCommonPoint
Tue May 15 19:01:09 [rsSync] replSet info rollback our last optime:   May 15 19:00:51:6
Tue May 15 19:01:09 [rsSync] replSet info rollback their last optime: May 15 19:01:09:19
Tue May 15 19:01:09 [rsSync] replSet info rollback diff in end of log times: -18 seconds
Tue May 15 19:01:10 [rsSync] replSet WARNING ignoring op on rollback no _id TODO : nimbus.system.indexes { ts: Timestamp 1337108400000|17, h: 1628369028235805797, op: "i", ns: "nimbus.system.indexes", o: { unique: true, name: "pascalquery_ns_key_start_ts_keyvals", key: { __ns__: 1, _key: 1, start_ts: 1, _keyval.a: 1, _keyval.b: 1, _keyval.c: 1, _keyval.d: 1, _keyval.e: 1, _keyval.f: 1, _keyval.g: 1, _keyval.h: 1 }, ns: "nimbus.wifi_daily_series", background: true } }
# ...
# Then for several minutes there are similar warnings
# ...
Tue May 15 19:03:52 [rsSync] replSet WARNING ignoring op on rollback no _id TODO : nimbus.system.indexes { ts: Timestamp 1337097600000|204, h: -3526710968279064473, op: "i", ns: "nimbus.system.indexes", o: { unique: true, name: "pascalquery_ns_key_start_ts_keyvals", key: { __ns__: 1, _key: 1, start_ts: 1, _keyval.a: 1, _keyval.b: 1, _keyval.c: 1, _keyval.d: 1, _keyval.e: 1, _keyval.f: 1, _keyval.g: 1, _keyval.h: 1 }, ns: "nimbus.wifi_daily_series", background: true } }
Tue May 15 19:03:54 [rsSync] replSet rollback found matching events at May 15 15:59:13:181
Tue May 15 19:03:54 [rsSync] replSet rollback findcommonpoint scanned : 6472020
Tue May 15 19:03:54 [rsSync] replSet replSet rollback 3 fixup

Successivamente, per qualche motivo, si verifica un altro rollback ...

Tue May 15 22:14:24 [rsSync] replSet rollback re-get objects: 13410 replSet too much data to roll back
Tue May 15 22:14:26 [rsSync] replSet syncThread: 13410 replSet too much data to roll back
Tue May 15 22:14:37 [rsSync] replSet syncing to: rs1m2.c9w.co:27017
Tue May 15 22:14:37 [rsSync] replSet syncThread: 13106 nextSafe(): { $err: "capped cursor overrun during query: local.oplog.rs", code: 13338 }
Tue May 15 22:14:48 [rsSync] replSet syncing to: rs1m2.c9w.co:27017
Tue May 15 22:15:30 [rsSync] replSet our last op time written: May 15 19:00:51:6
Tue May 15 22:15:30 [rsSync] replSet rollback 0
Tue May 15 22:15:30 [rsSync] replSet rollback 1
Tue May 15 22:15:30 [rsSync] replSet rollback 2 FindCommonPoint
Tue May 15 22:15:30 [rsSync] replSet info rollback our last optime:   May 15 19:00:51:6
Tue May 15 22:15:30 [rsSync] replSet info rollback their last optime: May 15 22:15:30:9
Tue May 15 22:15:30 [rsSync] replSet info rollback diff in end of log times: -11679 seconds
# More warnings matching the above warnings
Tue May 15 22:17:30 [rsSync] replSet rollback found matching events at May 15 15:59:13:181
Tue May 15 22:17:30 [rsSync] replSet rollback findcommonpoint scanned : 7628640
Tue May 15 22:17:30 [rsSync] replSet replSet rollback 3 fixup

Le uniche informazioni utili sui rollback che ho trovato sono queste note che non affrontano la "situazione di rollback bloccato". http://www.mongodb.org/display/DOCS/Replica+Sets+-+Rollbacks http://www.snailinaturtleneck.com/blog/2011/01/19/how-to-use-replica-set-rollbacks/

Quando un'istanza MongoDB entra in uno stato di rollback e i dati di rollback sono superiori a 300 MB di dati, è necessario intervenire manualmente. Rimarrà in uno stato di rollback fino a quando non si interverrà per salvare / rimuovere / spostare quei dati, quindi (ora il secondario) dovrebbe essere risincronizzato per riportarli in linea con il primario. Questo non deve essere una risincronizzazione completa, ma è il modo più semplice.

I rollback multipli sono un sintomo piuttosto che la causa di un problema. Il rollback si verifica solo quando un secondario non sincronizzato (a causa di un ritardo o di un problema con la replica) diventa primario e prende le scritture. Quindi, i problemi che causano che ciò avvenga in primo luogo sono ciò di cui bisogna occuparsi - il rollback stesso è qualcosa che devi affrontare come amministratore - ci sono troppe potenziali insidie ​​per MongoDB per riconciliare automaticamente i dati.

Se vuoi simularlo di nuovo a scopo di test, ho delineato come farlo qui:

http://comerford.cc/2012/05/28/simulating-rollback-on-mongodb/

Alla fine, questi dati verranno archiviati in una raccolta (nel DB locale) anziché scaricati su disco, il che offrirà opportunità per gestirli in modo più efficace:

https://jira.mongodb.org/browse/SERVER-4375

Al momento, tuttavia, una volta che si verifica un rollback, come è stato riscontrato, è necessario un intervento manuale.

Infine, il manuale contiene ora informazioni simili al blog di Kristina:

https://docs.mongodb.com/manual/core/replica-set-rollbacks

La "soluzione" che abbiamo usato è stata quella di eliminare completamente il nostro database dalla macchina che era bloccato in ROLLBACKmodalità e che permetteva al nuovo blanking SECONDARYdi risincronizzarsi dal master. Questa sembra una soluzione non ottimale perché, per quanto ne so, avevamo ancora molto spazio a disposizione, oplogquindi in teoria le macchine avrebbero dovuto essere in grado di risincronizzarsi.

Spero che qualcuno possa trovare una risposta migliore per questo.