[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:
Related
is related to SERVER-3265 Mongorestore: allow up-to ts/date val... Closed
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: SERVER-8685 - use old style append for OpTime
Branch: v2.2
https://github.com/mongodb/mongo/commit/4873c2bd64b71af9713eb75b222a7e13c6c4e747

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: SERVER-8685 Fix gcc compile
Branch: v2.2
https://github.com/mongodb/mongo/commit/32fe4cd8fd541e0c14fd28ac17096e9ff76ba726

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: SERVER-8685: mongorestore oplogLimit fixes

Conflicts:

src/mongo/tools/restore.cpp
Branch: v2.2
https://github.com/mongodb/mongo/commit/49cb7cab30855e58ef506c97d1280f2ca7d4dc6e

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: SERVER-8685 Fix gcc compile
Branch: master
https://github.com/mongodb/mongo/commit/f84a8a92cd95dc925d7285564bbce56efb73ba3b

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: SERVER-8685: mongorestore oplogLimit fixes
Branch: master
https://github.com/mongodb/mongo/commit/e63cc1987e8e69e53158a02f393b5a8c8993f492

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.

Generated at Thu Feb 08 03:18:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.