[DOCS-552] Instructions for resizing oplog problem Created: 25/Sep/12 Updated: 28/Sep/12 Resolved: 27/Sep/12 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Jeff lee | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 11 years, 20 weeks, 5 days ago |
| Description |
|
Hi, The documentation for resizing an oplog ( http://docs.mongodb.org/manual/tutorial/change-oplog-size/ ) indicates that the last entry from the current oplog should be saved. I believe this needs to be modified to take the last insert operation otherwise you may get a key with a $. Should be: db.temp.save( db.oplog.rs.find( {op:'i'}).sort( {$natural : -1} ).limit(1).next() ) Cheers. |
| Comments |
| Comment by auto [ 28/Sep/12 ] | |||||||||||||||
|
Author: {u'date': u'2012-09-27T15:52:42-07:00', u'email': u'samk@10gen.com', u'name': u'Sam Kleinman'}Message: | |||||||||||||||
| Comment by Jeff lee [ 25/Sep/12 ] | |||||||||||||||
|
Yeah, I've been planning on using the fromMigrate field to seed some reporting systems downstream so it's been on my mind. Thanks. btw - I think there's a typo in that command. Should it be runCommand on the temp collection you want to use to seed the new oplog so that the complete sequence looks something like:
| |||||||||||||||
| Comment by Scott Hernandez (Inactive) [ 25/Sep/12 ] | |||||||||||||||
|
Jeff, if you wanted to represent the entry yes, but not if you just want the system to start replication from that point. Really this mechanism of seeding the first entry using the shell has some issues because of the validation done by the shell to keep the user from doing things that the server does when inserting into the oplog. We should probably note that this method may produce an inconsistent results for external apps, like those expecting every oplog entry to be one of the known operation types. This might be a better way would be to bypass those checks (using a special testing command):
| |||||||||||||||
| Comment by Jeff lee [ 25/Sep/12 ] | |||||||||||||||
|
Hey Scott, I think the fromMigrate field will be needed as well in case the oplog is being tailed? Thanks. | |||||||||||||||
| Comment by Scott Hernandez (Inactive) [ 25/Sep/12 ] | |||||||||||||||
|
Probably best to just return the fields needed and not the actual op data:
|