MONGODB 복제본 세트 SECONDARY가 롤백 상태에 멈춤

우리 MongoDB를 최근 자동 업데이트 중에 PRIMARY(가), PRIMARY사임은 영구적으로 들어갔다 ROLLBACK상태입니다.

ROLLBACK상태 에서 몇 시간이 지난 후에도 mongodb 데이터베이스 디렉토리 .bson의 rollback디렉토리에 여전히 롤백 파일이 없습니다 . 그것은, 그리고 우리의 로그 파일에있는이 줄은 : 프로세스가 실패 [rsSync] replSet syncThread: 13410 replSet too much data to roll back했음을 나타냅니다 ROLLBACK.

정확히 무엇이 잘못되었는지 분석하는 데 도움이 필요합니다.

• 로그에서 서로 다른 두 가지 롤백이 발생했습니다. 이 경우입니까 아니면 3 시간이 걸렸습니까?
• 첫 번째 롤백 (19:00 시간)이 성공한 경우 왜 ou rollback디렉토리에 아무것도 나타나지 않았 습니까?
• 모든 경고의 원인에 대한 추측? 롤백 실패와 관련이있을 수 있습니까?
• 첫 번째 데이터로 인해 18 초의 데이터가 손실 되었습니까 ROLLBACK?
• "고착 ROLLBACK상태"문제 에 대한 일반적인 해결책이 있습니까? 결국 전체 DB를 연결하고 기본 데이터베이스에서 다시 동기화해야했습니다.

관련 로그 라인은 다음과 같습니다.

# 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

그런 다음 나중에 어떤 이유로 다른 롤백이 발생합니다 ...

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

내가 찾은 롤백에 대한 유용한 정보는 "롤백 상황에 빠지지 않음"을 다루지 않는 참고 사항입니다. http://www.mongodb.org/display/DOCS/Replica+Sets+-+Rollbacks http://www.snailinaturtleneck.com/blog/2011/01/19/how-to-use-replica-set-rollbacks/

MongoDB 인스턴스가 롤백 상태가되고 롤백 데이터가 300MB보다 큰 경우 수동으로 개입해야합니다. 해당 데이터를 저장 / 제거 / 이동하기위한 조치를 취할 때까지 롤백 상태로 유지됩니다. 그런 다음 (현재 보조)를 다시 동기화하여 기본과 일치하도록 다시 동기화해야합니다. 이것은 완전히 재 동기화 될 필요는 없지만 가장 간단한 방법입니다.

여러 롤백은 문제의 원인이 아니라 증상입니다. 롤백은 지연되거나 복제 문제로 인해 동기화되지 않은 보조 노드가 기본 노드가되어 쓰기를 수행하는 경우에만 발생합니다. 따라서 롤백 자체는 관리자가 처리해야 할 문제입니다. MongoDB가 데이터를 자동으로 조정할 수있는 잠재적 인 함정이 너무 많습니다.

테스트 목적으로 이것을 다시 시뮬레이션하려면 여기에서 수행하는 방법을 간략히 설명했습니다.

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

결국이 데이터는 디스크에 덤프되지 않고 컬렉션 (로컬 DB)에 저장되므로보다 효과적으로 처리 할 수 ​​있습니다.

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

그러나 롤백이 발생하면 수동 개입이 필요합니다.

마지막으로 매뉴얼에는 Kristina의 블로그와 비슷한 정보가 포함되어 있습니다.

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

우리가 사용한 "솔루션"은 ROLLBACK모드 에서 멈춰있는 머신에서 데이터베이스를 완전히 가져 오고 새로 블랭크 SECONDARY를 마스터에서 다시 동기화 하는 것이 었습니다 . 내가 알 수 있듯이 우리는 여전히 충분한 공간을 가지고 oplog있었기 때문에 이론적으로 기계가 다시 동기화 할 수 있어야 했기 때문에 이것은 차선책으로 보입니다 .

잘하면 누군가가 이것에 대한 더 나은 대답을 얻을 수 있기를 바랍니다.