[SERVER-8685] mongorestore oplogReplay + oplogLimit should not be compatible with any other collections Created: 22/Feb/13 Updated: 11/Jul/16 Resolved: 28/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Tools |
| Affects Version/s: | None |
| Fix Version/s: | 2.2.4, 2.4.0-rc2 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Scott Hernandez (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | mongorestore, oplog, oplogLimit, tools | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
If you are replaying the oplog.bson file with --oplogLimit no other databases/collections should be restored, and an error should tell you that you should remove the collections before restoring with those options. This feature was meant to just apply to oplog replay exclusively. In addition the timestamp (from --oplogLimit <ts>) will be validated to be greater than the top (latest) oplog entry. |
| Comments |
| Comment by auto [ 15/Mar/13 ] |
|
Author: {u'date': u'2013-03-15T16:11:57Z', u'name': u'Dan Pasette', u'email': u'dan@10gen.com'}Message: |
| Comment by auto [ 15/Mar/13 ] |
|
Author: {u'date': u'2013-03-01T13:04:19Z', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}Message: |
| Comment by auto [ 15/Mar/13 ] |
|
Author: {u'date': u'2013-02-28T22:34:30Z', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: Conflicts: src/mongo/tools/restore.cpp |
| Comment by auto [ 01/Mar/13 ] |
|
Author: {u'date': u'2013-03-01T13:04:19Z', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}Message: |
| Comment by auto [ 28/Feb/13 ] |
|
Author: {u'date': u'2013-02-28T22:34:30Z', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: |
| Comment by Scott Hernandez (Inactive) [ 28/Feb/13 ] |
|
What about just skipping any oplog entry which has already been applied – older that the newest oplog entry. So the entries applied are the range of current oplog head to oploglimit. |
| Comment by Daniel Pasette (Inactive) [ 27/Feb/13 ] |
|
If we're checking that the --oplogLimit argument is after the last oplog entry timestamp in the destination, we should also check that the first source entry we restore is before the last oplog entry in the destination. |
| Comment by Richard Kreuter (Inactive) [ 22/Feb/13 ] |
|
For future reference, several pairs of us discussed some options here: one way to not be compatible is to error out of the dump folder contains more things than just the oplog bson file; another is to ignore everything but the oplog bson file. Another feature that Scott and Dan independently proposed was to have mongorestore --oplogReplay look around for an oplog file at $dump/oplog.bson, $dump/local/oplog.rs.bson, $dump/local/oplog.$main.bson. Also --oplogLimit should check to see that the last entry in the oplog of the node being populated is strictly older than the timestamp specified to oplogLimit. |