MongoDBレプリカセットSECONDARYが「ROLLBACK」状態でスタック

私たちのmongodbの最近の自動更新中に、降格PRIMARYしたときPRIMARYに永久にROLLBACK状態になりました。

ROLLBACK状態で数時間経過した後も、mongodbデータベースディレクトリのディレクトリにはロールバック.bsonファイルがありませんでしたrollback。それと、ログファイルの次の行も[rsSync] replSet syncThread: 13410 replSet too much data to roll back、ROLLBACKプロセスが失敗したことを示しているようです。

何がうまくいかなかったかを分析するのを手伝ってほしい。

• ログで2つの異なるロールバックが発生したようです。それはそうですか、それとも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

ただし、現時点では、ロールバックが発生すると、ご存じのとおり、手動による介入が必要になります。

最後に、このマニュアルにはクリスティーナのブログと同様の情報が含まれています。

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

私たちが最終的に使用した「解決策」は、ROLLBACKモードで動かなくなったマシン上にデータベースを完全に置き、新しくブランクSECONDARYしたものをマスターから再同期できるようにすることでした。これは最適とは言えないソリューションのようです。なぜなら、私が知る限りでは、まだ十分なスペースがあるoplogため、理論上はマシンが再同期できるはずです。

うまくいけば、誰かがこれに対するより良い答えを思い付くでしょう。