[SERVER-22766] Dynamic oplog sizing for WiredTiger nodes Created: 19/Feb/16  Updated: 23/Oct/19  Resolved: 05/Jul/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.4.19, 3.5.10

Type: New Feature Priority: Major - P3
Reporter: Shakir Sadikali Assignee: Geert Bosch
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-18010 Allow resizing oplog with CollMod on WT Closed
Documented
is documented by DOCS-10544 Docs for SERVER-22766: Dynamic oplog ... Closed
Duplicate
is duplicated by SERVER-2603 command to resize capped collection (... Closed
is duplicated by SERVER-22847 Online change oplog size when using w... Closed
Related
related to SERVER-31587 ReplBatcher has a long-running Operat... Closed
related to SERVER-37749 replSetResizeOplog command does not v... Closed
related to SERVER-44029 Remove global X lock for replSetResiz... Closed
related to SERVER-31654 ReplBatcher should recalculate batch ... Backlog
related to SERVER-30460 Grow the oplog when the replication c... Closed
is related to SERVER-38501 swap out new ActionType for replSetRe... Closed
is related to SERVER-30151 Size specification for oplog resizing Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.4
Participants:

 Description   

Proposed title: Dynamic oplog sizing of replica set

Issue Status as of Jul 10, 2017

FEATURE DESCRIPTION
This new feature enables the dynamic resizing of a node's oplog, allowing users to grow and shrink the oplog to satisfy the operational needs of each node in a replica set.

VERSIONS
This feature is available in the 3.5.10 and newer development versions of MongoDB, and in the 3.6 and newer production releases.

RATIONALE
In a MongoDB replica set, the oplog is a special capped collection used to replicate data to other nodes. Users may specify the size of the oplog for each node when deploying a replica set, but altering that size required maintenance.

This new feature bypasses the need for maintance and allows users to dynamically change the size of the oplog in MongoDB nodes running with the WiredTiger storage engine only (nodes running the MMAPv1 storage engine still need to follow the maintenance procedure linked above).

OPERATION
To display the size of the oplog, one can use the stats() command. Here's a replica set primary node with a 9.1GB oplog:

replset:PRIMARY> use local
replset:PRIMARY> db.oplog.rs.stats()
{
        "ns" : "local.oplog.rs",
        "size" : 6781,
        "count" : 60,
        "avgObjSize" : 113,
        "storageSize" : 36864,
        "capped" : true,
        "max" : -1,
        "maxSize" : NumberLong("9790804377"),
        ...
}

The size of the oplog is displayed at deployment time in the logs as follows:

2017-07-17T17:47:11.870-0400 I REPL     [replication-0] creating replication oplog of size: 9337MB...

Users can change the size of the oplog with the replSetResizeOplog command, specifying a size in MB. For example:

replset:PRIMARY> use admin
replset:PRIMARY> db.runCommand({replSetResizeOplog:1, size: 16384})
{ "ok" : 1, "operationTime" : Timestamp(1500329291, 1) }

The command above changes the oplog size to 16384 MB (16GB/17179869184 bytes). This operation is recorded in the logs as follows:

2017-07-17T17:52:40.396-0400 I STORAGE  [conn11] replSetResizeOplog success, currentSize:17179869184

The output of the stats() command also reflects the change:

replset:PRIMARY> use local
replset:PRIMARY> db.oplog.rs.stats()
{
        "ns" : "local.oplog.rs",
        "size" : 6781,
        "count" : 60,
        "avgObjSize" : 113,
        "storageSize" : 36864,
        "capped" : true,
        "max" : -1, 
        "maxSize" : NumberLong("17179869184")
        ...
}

ADDITIONAL NOTES
Reducing the size of the oplog removes data from it. Reducing the size of the oplog in a given node may cause any members of a replica set syncing from that node to become stale and need a resync.

Original description

It would be very, very handy to have a method to alter the oplog size for an entire replicaset at the same time. That is, issue a command on the primary, it expands its oplog size, and the changes trickle down to the replicas.

Better yet would be a dynamic oplog where it doesn't need to be a specific size. Capped collections have advantages, I understand, but perhaps there are ways around limitations of uncapped ones for oplog purposes.



 Comments   
Comment by Githook User [ 07/Dec/18 ]

Author:

{'name': 'wolfkdy', 'email': 'kdy71107216@aliyun.com', 'username': 'wolfkdy'}

Message: SERVER-22766 wiredtiger engine support update oplogsize online

(cherry picked from commit 93beb0234eba9dc58ab6070ad472022f96e019e6)
Branch: v3.4
https://github.com/mongodb/mongo/commit/0802b5f4033e481cc3c2830d6f14a3fdd5b3ffcd

Comment by Githook User [ 05/Jul/17 ]

Author:

{u'username': u'wolfkdy', u'name': u'wolfkdy', u'email': u'kdy71107216@aliyun.com'}

Message: SERVER-22766 wiredtiger engine support update oplogsize online
Branch: master
https://github.com/mongodb/mongo/commit/93beb0234eba9dc58ab6070ad472022f96e019e6

Comment by Geert Bosch [ 08/Jun/17 ]

We'll be merging your change soon

Comment by deyukong [ 26/May/17 ]

Would you please take some time to review my last commit, thanks!

Comment by deyukong [ 17/May/17 ]

@Geert Bosch
Thanks for taking time.
I've read your comments and taken your suggestions.
You may take a look at my latest changes.
Hoping for your reply

Comment by deyukong [ 16/May/17 ]

I refined my code, to update codes below:

use checkAuthForCommand instead of addRequiredPrivileges
merge from upstream/master, resolve conflicts, use new api to get collection
do a fully new compile with no errors and check everything works ok.
I think it is the right time to merge the code. If time lasts longer, new conflicts will appear.
Hoping for your reply!

Comment by deyukong [ 15/May/17 ]

Happy Monday!
I'm here again.
Ask the old question.
Do you have further plans about this issue and my pr?
Hoping for your reply!

Comment by deyukong [ 11/May/17 ]

I've carefully read @Spencer T Brody's review comments, optimized my code and updated the pull request.

Comment by deyukong [ 30/Apr/17 ]

I‘ve carefully read @Geert Bosch's review comments, optimized my code and updated the pull request.

Comment by deyukong [ 06/Mar/17 ]

I did not pass “resizeOplog” through the replication subsystem since oplogSize should be metadata of a single mongod rather than a repl-set.

Comment by Ramon Fernandez Marina [ 04/Mar/17 ]

Thanks for taking the time to create a pull request wolf_kdy, we'll take a look and get back to you.

Comment by deyukong [ 04/Mar/17 ]

Hi, I devoted a pull request to solve this issue.
pull request
I have signed the contribution agreement, changed and passed related unittests.
Intergration-tests are also made to ensure the correctness under high pressure.
The two bug issues devoted last year by me can be a proof that I'm experienced in mongodb sourcecode. So plz take a serious look into the pull request.
Hoping for your reply, thanks!

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