[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: DOCS-552: correction to procedure
Branch: master
https://github.com/mongodb/docs/commit/c355c0333fdfdf2ae0e9cac2060f8aca022c5098

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:

use local
 
// save the last insert
db.temp.runCommand('godinsert', {obj:db.oplog.rs.find({op:'i'}).sort({$natural:-1}).limit(-1).next()})
 
// ensure you've got a valid entry
db.temp.find()
 
// drop the old oplog and create a larger one
db.oplog.rs.drop()
db.runCommand({ create : "oplog.rs", capped : true, size : [new size in bytes] })
 
// transfer the last oplog entry and validate
db.oplog.rs.save(db.temp.findOne())
db.oplog.rs.find()

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):

> use local
> db.oplog.rs.runCommand("godinsert", {obj:db.oplog.rs.find({op:'i'}).sort( {$natural : -1} ).limit(1).next()} ) //bypass field checks

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:

db.temp.save( db.oplog.rs.find({op:'i'}, {ts:1, h:1, _id:0}).sort( {$natural : -1} ).limit(1).next() )

Generated at Thu Feb 08 07:38:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.