MongoDB Replica Set SECONDARY ติดอยู่ในสถานะ 'ROLLBACK`

ในระหว่างการอัพเดทอัตโนมัติครั้งล่าสุดของ MongoD ของเราPRIMARYเมื่อPRIMARYก้าวลงมาอย่างถาวรก็เข้าสู่ROLLBACKสถานะอย่างถาวร

หลังจากหลายชั่วโมงในROLLBACKสถานะยังคงไม่มี.bsonไฟล์ย้อนกลับในrollbackไดเร็กทอรีในไดเร็กทอรีฐานข้อมูล mongodb ที่และบรรทัดนี้ในไฟล์บันทึกของเรา: [rsSync] replSet syncThread: 13410 replSet too much data to roll backดูเหมือนว่าจะบ่งชี้ว่าROLLBACKกระบวนการล้มเหลว

ฉันต้องการความช่วยเหลือในการวิเคราะห์สิ่งที่ผิดพลาด

• ดูเหมือนจะมีการย้อนกลับสองแบบที่แตกต่างกันเกิดขึ้นในบันทึกของเรา เป็นเช่นนั้นหรือเป็นกรณีที่ใช้เวลา 3 ชั่วโมง?
• หากการย้อนกลับครั้งแรก (เวลา 19:00 น.) ประสบความสำเร็จทำไมไม่มีสิ่งใดปรากฏในrollbackไดเรกทอรีของคุณ
• มีการเดาสาเหตุของคำเตือนเหล่านั้นหรือไม่? นั่นอาจเกี่ยวข้องกับความล้มเหลวในการย้อนกลับใช่ไหม
• เราสูญเสียข้อมูลไป 18 วินาทีเนื่องจากครั้งแรกROLLBACKใช่หรือไม่
• มีวิธีแก้ปัญหาทั่วไปสำหรับปัญหา "ติดอยู่ในROLLBACKสถานะ" หรือไม่? เราต้องไปที่ฐานข้อมูลทั้งหมดของเราและซิงค์จากหลักอีกครั้ง

บรรทัดบันทึกที่เกี่ยวข้องคือ:

# 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-rollback/

เมื่ออินสแตนซ์ MongoDB เข้าสู่สถานะย้อนกลับและข้อมูลย้อนกลับมากกว่า 300MB ของข้อมูลคุณจะต้องเข้าไปแทรกแซงด้วยตนเอง มันจะยังคงอยู่ในสถานะย้อนกลับจนกว่าคุณจะดำเนินการเพื่อบันทึก / ลบ / ย้ายข้อมูลนั้น (ตอนนี้รอง) ควรได้รับการซิงค์อีกครั้งเพื่อนำข้อมูลนั้นกลับมาสอดคล้องกับหลัก นี่ไม่จำเป็นต้องทำการซิงค์ใหม่ทั้งหมด แต่นั่นเป็นวิธีที่ง่ายที่สุด

การย้อนกลับหลายครั้งเป็นอาการแทนที่จะเป็นสาเหตุของปัญหา การย้อนกลับเกิดขึ้นเมื่ออุปกรณ์สำรองที่ไม่ซิงค์ (เนื่องจากความล่าช้าหรือปัญหาเกี่ยวกับการจำลอง) กลายเป็นอุปกรณ์หลักและทำการเขียน ดังนั้นปัญหาที่ทำให้เกิดขึ้นในตอนแรกคือสิ่งที่ต้องได้รับการดูแล - การย้อนกลับนั้นเป็นสิ่งที่คุณต้องจัดการในฐานะผู้ดูแลระบบ - มีข้อผิดพลาดที่อาจเกิดขึ้นมากเกินไปสำหรับ MongoDB ที่จะตรวจสอบข้อมูลโดยอัตโนมัติ

หากคุณต้องการจำลองสถานการณ์นี้อีกครั้งเพื่อวัตถุประสงค์ในการทดสอบฉันได้อธิบายวิธีการดังกล่าวที่นี่:

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

ในที่สุดข้อมูลนี้จะถูกเก็บไว้ในคอลเลกชัน (ในฐานข้อมูลท้องถิ่น) แทนที่จะทิ้งลงดิสก์ซึ่งจะนำเสนอโอกาสในการจัดการกับมันได้อย่างมีประสิทธิภาพมากขึ้น:

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

ในขณะนี้เมื่อย้อนกลับเกิดขึ้นตามที่คุณพบจำเป็นต้องมีการแทรกแซงด้วยตนเอง

ท้ายที่สุดคู่มือมีข้อมูลที่คล้ายกับบล็อกของ Kristina ในขณะนี้:

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

"การแก้ปัญหา" ที่เราใช้ในท้ายที่สุดคือการซ่อนฐานข้อมูลของเราบนเครื่องซึ่งติดอยู่ในROLLBACKโหมดและอนุญาตให้ผู้ทำข้อมูลใหม่SECONDARYที่ซิงค์ใหม่จากต้นแบบ ดูเหมือนว่าจะเป็นวิธีแก้ปัญหาที่ไม่ดีนักเพราะใกล้เท่าที่ฉันจะบอกได้ว่าเรายังมีพื้นที่เหลือเฟือoplogดังนั้นเครื่องจักรควรมีทฤษฎีในการซิงค์ได้อีกครั้ง

หวังว่าบางคนจะได้คำตอบที่ดีกว่านี้