[SERVER-7200] use oplog as op buffer on secondaries Created: 28/Sep/12 Updated: 06/Feb/18 Resolved: 23/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 2.2.0 |
| Fix Version/s: | 3.2.11, 3.3.12 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 5 |
| Labels: | code-and-test | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Completed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2016-08-29 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Currently, we use an in-memory queue to buffer operations between the network reader and the op writer. Instead, we could simply use the local.oplog collection as the buffer. Added advantage: we'll know what operations in the batch were actively being applied if we crash in the middle of a batch. |
| Comments |
| Comment by pravin dwiwedi [ 14/Feb/17 ] |
|
Thanks Thomas for your quick response. But I am not able to start the affected node(mongod), as soon as I start the node it gets started but give below exception and gets shutdown. Regards |
| Comment by Kelsey Schubert [ 14/Feb/17 ] |
|
Once a node has entered this state, the only way to resolve the issue is to resync the affected node by performing an initial sync. Upgrading would prevent the node from reaching this inconsistent state, but would not correct a node already affected by this issue. Kind regards, |
| Comment by pravin dwiwedi [ 14/Feb/17 ] |
|
Hi Team, Thanks for fixes. I am facing the same problem while running on Mongo 3.2.7. Whenever I restart the server it gives exception and Mongod gets stopped-- _2017-02-14T11:00:08.580+0000 I REPL [rsBackgroundSync] Starting rollback due to OplogStartMissing: our last op time fetched: (term: 36, timestamp: Feb 13 22:53:33:3). source's GTE: (term: 37, timestamp: Feb 13 22:53:36:1) hashes: (3451672896402616640/2249844032076922861) ***aborting after fassert() failure Is there any work around to fix this issue without upgrading the Mongo? Regards |
| Comment by Githook User [ 20/Jan/17 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'redbeard0531@gmail.com'}Message: (cherry picked from commit 0b76764eac7651ddba4c82c504aa7e8d785087c2)
(cherry picked from commit 99e19b1ded425a1d859a9bc52fd5c2712e71f83a)
(cherry picked from commit 2dec7e9a15af8e0fc4d8e68ed40e3abe90b3a3b3)
This is a special case of (cherry picked from commit 8e7231a38341d68fb2cdc60509687397e9a17741)
(cherry picked from commit ef1f1739d6cbff9fb4ddbcc77d467f183c0ab9f2) (all cherry picked from v3.4 commit f4cab348460c90fcd506b2d46bf8c830b7b87379) |
| Comment by Githook User [ 13/Jan/17 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: (cherry picked from commit 0b76764eac7651ddba4c82c504aa7e8d785087c2)
(cherry picked from commit 99e19b1ded425a1d859a9bc52fd5c2712e71f83a)
(cherry picked from commit 2dec7e9a15af8e0fc4d8e68ed40e3abe90b3a3b3)
This is a special case of (cherry picked from commit 8e7231a38341d68fb2cdc60509687397e9a17741)
(cherry picked from commit ef1f1739d6cbff9fb4ddbcc77d467f183c0ab9f2) |
| Comment by Githook User [ 03/Jan/17 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: This is a special case of |
| Comment by Githook User [ 17/Oct/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'redbeard0531@gmail.com'}Message: Manual backport of 34c6c691a038eac1ac3ee16e1eedc54aab964774 along with fixes b5d2b06f8a08171fd96ef8d128c4f7ecedcb8f93 |
| Comment by Githook User [ 17/Oct/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: (cherry picked from commit b06901cd83b2a985aa50f9a699f3d63dcd28476d) |
| Comment by Githook User [ 16/Sep/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: Fixes a small but important bug in |
| Comment by Githook User [ 23/Aug/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: |
| Comment by Githook User [ 23/Aug/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: |
| Comment by Githook User [ 23/Aug/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: |
| Comment by Githook User [ 23/Aug/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: |
| Comment by Mathias Stearn [ 17/Aug/16 ] |
|
ramon.fernandez, I'm moving this to 3.3.12. We either need to get this in or disable multi-threaded oplog writing on secondaries before going into RCs, otherwise it will make upgrade/downgrade between 3.4 RCs a pain. This isn't an issue for upgrade/downgrade to/from 3.2 because it writes the oplog in a single thread. |