Bản sao MongoDB Đặt THỨ HAI Bị kẹt trong trạng thái `ROLLBACK`

Trong một bản cập nhật tự động gần đây của mongodb của chúng tôi PRIMARY, khi PRIMARYbước xuống, nó vĩnh viễn đi vào ROLLBACKtrạng thái.

Sau vài giờ ở ROLLBACKtrạng thái, vẫn không có .bsontệp rollback trong rollbackthư mục trong thư mục cơ sở dữ liệu mongodb. Điều đó, và cũng là dòng này trong tệp nhật ký của chúng tôi : [rsSync] replSet syncThread: 13410 replSet too much data to roll back, dường như chỉ ra rằng ROLLBACKquá trình không thành công.

Tôi muốn một số trợ giúp phân tích chính xác những gì đã sai.

• Nó xuất hiện hai rollback khác nhau xảy ra trong nhật ký của chúng tôi. Đó là trường hợp hay nó đã mất 3 giờ?
• Nếu rollback đầu tiên (lúc 19:00 giờ) thành công, tại sao không có gì xuất hiện trong rollbackthư mục ou ?
• Bạn có đoán được nguyên nhân của tất cả những cảnh báo đó không? Điều đó có thể liên quan đến thất bại rollback?
• Có phải chúng ta đã mất 18 giây dữ liệu do lần đầu tiên ROLLBACK?
• Có một giải pháp chung cho ROLLBACKvấn đề "mắc kẹt trong trạng thái" không? Chúng tôi cuối cùng đã phải vòi toàn bộ DB của chúng tôi và đồng bộ hóa lại từ chính.

Các dòng nhật ký liên quan là:

# 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

Sau đó, vì một số lý do, một sự phục hồi khác xảy ra ...

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

Thông tin hữu ích duy nhất về rollback tôi đã tìm thấy là những ghi chú không giải quyết được "tình trạng bị kẹt trong tình huống". http://www.mongodb.org/display/DOCS/Replica+Sets+-+Rollbacks http://www.snailinaturtleneck.com/blog/2011/01/19/how-to-use-replica-set-rollbacks/

Khi một phiên bản MongoDB chuyển sang trạng thái Rollback và dữ liệu rollback lớn hơn 300MB dữ liệu, bạn phải can thiệp thủ công. Nó sẽ ở trạng thái khôi phục cho đến khi bạn thực hiện hành động lưu / xóa / di chuyển dữ liệu đó, sau đó (bây giờ là thứ yếu) sẽ được gắn lại để đưa nó trở lại phù hợp với dữ liệu chính. Đây không phải là một đồng bộ lại đầy đủ, nhưng đó là cách đơn giản nhất.

Nhiều rollback là một triệu chứng chứ không phải là nguyên nhân của một vấn đề. Phục hồi chỉ xảy ra khi một thứ cấp không đồng bộ (do độ trễ hoặc do sự cố sao chép) trở thành chính và mất ghi. Vì vậy, những vấn đề gây ra điều đó xảy ra ngay từ đầu là vấn đề cần được quan tâm - chính việc khôi phục lại là điều bạn cần giải quyết với tư cách quản trị viên - có quá nhiều cạm bẫy tiềm tàng để MongoDB tự động điều chỉnh dữ liệu.

Nếu bạn muốn mô phỏng điều này một lần nữa cho mục đích thử nghiệm, tôi đã phác thảo cách thực hiện ở đây:

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

Cuối cùng, dữ liệu này sẽ được lưu trữ trong một bộ sưu tập (trong DB cục bộ) thay vì được đổ vào đĩa, điều này sẽ mang lại cơ hội để đối phó với nó hiệu quả hơn:

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

Tuy nhiên, hiện tại, một khi sự quay trở lại xảy ra, như bạn đã tìm thấy, cần phải có sự can thiệp thủ công.

Cuối cùng, hướng dẫn chứa thông tin tương tự như blog của Kristina bây giờ:

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

"Giải pháp" mà chúng tôi đã kết thúc bằng cách sử dụng hoàn toàn cơ sở dữ liệu của chúng tôi trên máy bị kẹt trong ROLLBACKchế độ và cho phép đồng bộ mới được SECONDARYđồng bộ hóa lại từ chủ. Đây có vẻ như là một giải pháp tối ưu bởi vì, như tôi có thể nói, gần như chúng ta vẫn còn nhiều không gian trên oplogđó, theo lý thuyết, các máy móc có thể đồng bộ hóa lại.

Hy vọng ai đó sẽ đưa ra một câu trả lời tốt hơn cho điều này.