[SERVER-22030] Abort if oplog is uncapped when starting in repl mode Created: 30/Dec/15 Updated: 08/Feb/17 Resolved: 19/May/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.0.7 |
| Fix Version/s: | 3.2.13, 3.3.8 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Kevin Pulo | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Backport Completed: | |||||||||||||||||||||||||
| Sprint: | Repl 15 (06/03/16) | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
In 3.0.7 (MMAPv1), oplog entries have been observed to be in non-monotonic order on secondaries where the oplog is not a capped collection.
|
| Comments |
| Comment by Githook User [ 08/Feb/17 ] | |||||||||||||||||||||||||||||
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: (cherry picked from commit 4e7318bcb63eea1c0cbe453bede94d0e908b351c) | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 19/May/16 ] | |||||||||||||||||||||||||||||
|
Note this only affects MMAP storage engine, which does not guarantee insertion order in non-capped collections. | |||||||||||||||||||||||||||||
| Comment by Githook User [ 19/May/16 ] | |||||||||||||||||||||||||||||
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 17/May/16 ] | |||||||||||||||||||||||||||||
|
Since version 3.0.9, in the 3.0 branch, users no longer have the ability to create an uncapped oplog (even implicitly). | |||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 31/Dec/15 ] | |||||||||||||||||||||||||||||
|
I have been able to repro to confirm the impact — an uncapped oplog, at least on 3.0.8 MMAPv1 secondaries, results in oplog entries that are out of order. I wouldn't be surprised if the impact was wider (eg. perhaps also primaries, perhaps also WT, perhaps also 3.2/master), but it doesn't really matter because even this alone is bad enough. The repro I used was simple:
| |||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 30/Dec/15 ] | |||||||||||||||||||||||||||||
|
Sure. Since "downgrading" from a replset to a standalone isn't really a thing, there isn't really any possibility of a "vestigial" oplog. | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 30/Dec/15 ] | |||||||||||||||||||||||||||||
|
I think it would be easiest if we simply refuse to start, in repl mode, if the oplog is not capped. Not sure we need a warning for standalone mode, since a user's reason for starting in standalone mode is almost guaranteed to be because mongod is refusing to start in repl mode due to an uncapped oplog. | |||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 30/Dec/15 ] | |||||||||||||||||||||||||||||
|
Refusing to start would be fine, as long as it's only when replication (or master/slave) is enabled. Refusing to start irrespective of supplied options is not okay, because it could effectively lock people out of their instance without any way of fixing the problem that's stopping the server from starting (ala In the absence --master, --replSet or replication.replSetName, I guess a startup warning would be most appropriate. Though I could probably be talked out of that (ie. no change from the current behaviour). | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 30/Dec/15 ] | |||||||||||||||||||||||||||||
|
Should it be a warning, or simply refuse to start if the oplog isn't capped? |