[DOCS-10808] Update oplog resizing instructions in advance of 3.6 Created: 19/Sep/17  Updated: 30/Oct/23  Resolved: 09/Nov/17

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: Louisa Berger Assignee: Kevin Albertson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to DOCS-12231 3.6 and 4.0 oplog resize procedures o... Closed
Participants:
Days since reply: 6 years, 13 weeks, 6 days ago
Epic Link: DOCS: 3.6 Server

 Description   

If you follow the oplog resizing directions in the docs (https://docs.mongodb.com/manual/tutorial/change-oplog-size/) for a 3.5.13 mmapv1 replica set, secondaries get into an error state when they are re-added to the replica set :

2017-09-19T14:01:17.567-0400 E REPL     [rsBackgroundSync] sync producer problem: Location40414: BSON field 'OplogEntryBase.op' is missing but a required field

Note : The procedure in the docs works fine on 3.4.9.

Not sure if this is just a change that needs to be made to the docs for 3.6, or a problem from 3.6 changes. milkie suggested I assign this to replication, but feel free to reassign.



 Comments   
Comment by Githook User [ 09/Nov/17 ]

Author:

{'name': 'Kevin Albertson', 'username': 'kevinAlbs', 'email': 'kevin.albertson@10gen.com'}

Message: DOCS-10808 fix oplog resize instructions on mmap
Branch: master
https://github.com/mongodb/docs/commit/44b21c3f70e1fc41f5ea3584d168e8c86f40b8de

Comment by Spencer Brody (Inactive) [ 20/Sep/17 ]

I think this approach should work for all mongodb versions, not just 3.6.

Comment by Spencer Brody (Inactive) [ 20/Sep/17 ]

Okay, I figured out why it was written the way it was. The problem is that oplog entries can contain update modifiers (like $set), but you can't actually store documents into collections with field names that start with a dollar sign. So I think the thing to do is grab the whole oplog entry, then clear out the 'o' and 'o2' fields before storing it. So where the docs currently say:

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

Change to

var oplogEntry = db.oplog.rs.find().sort({$natural: -1}).limit(1).next();
oplogEntry.op = 'n'; // Change the entry to a no-op
oplogEntry.o = {}; // Remove any update modifiers that would prevent saving the oplog entry to a normal collection.
oplogEntry.o2 = {};
db.temp.save(oplogEntry);

Comment by Louisa Berger [ 20/Sep/17 ]

spencer – is this what you'd recommend for all mongodb versions, or just 3.6?

Comment by Eric Milkie [ 19/Sep/17 ]

Note this will also affect anyone who has scripts that copy oplog entries for this purpose.

Comment by Spencer Brody (Inactive) [ 19/Sep/17 ]

I have converted this into a documentation request. The problem with the existing documented procedure is that when saving the seed oplog document to the new oplog we only save the 'ts' and 'h' fields, but we need to save the entire oplog entry.

Comment by Eric Milkie [ 19/Sep/17 ]

Also I suspect that you would get this error for any storage engine, although there is no longer a need to do this procedure for WiredTiger now that we have online oplog resizing there.

Comment by Eric Milkie [ 19/Sep/17 ]

My initial research suggests that this behavior changed when we converted oplog entry into an IDL. It may be that we want to keep this behavior; however, we'll have to change documentation, and it will be a backwards-breaking change for those users who have been following the old directions.

Generated at Thu Feb 08 08:01:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.