Increasing Oplog size - one-shot or step-by-step?

Ops and Admin Replication
1

Hello community,

We have a pretty old MongoDB self-managed 3 node ReplicaSet cluster running on 4.2.11.

The current Oplog size is as below:

    "logSizeMB" : 35785.184814453125,
    "usedMB" : 35612.19,
    "timeDiff" : 33393,
    "timeDiffHours" : 9.28,

so about 9.3 hours on each of the nodes. I’d like to increase this value to at least 18 hours, so have the logSize top from 35GB to about 72GB.

I checked the official documentation for version 4.2 on doing this
"
db.adminCommand({replSetResizeOplog: 1, size: 72000})

Perform these steps on each secondary replica set member first. Once you have changed the oplog size for all secondary members, perform these steps on the primary."

That’s pretty clear.

What is not specified in the docs and was hoping to get an answer on is:

  • Can I just jump directly from 35GB to 70 GB or do i need to do this in steps of 10, 15GB ? Is there any performance impact on doing it one way or another ?
  • How big can I go, assuming I have unlimited storage ? I saw in another community post that you can go up to 2 days without issues. Is this accurate ?

Thanks a lot for the help.

1 Like
2

Thanks for sharing this question! Increasing the oplog size in one step is usually fine as long as disk space allows, but doing it gradually can be safer if you’re monitoring impact on performance. Helpful thread!

3

Hello John,

Thanks for answering but it’s still a bit unclear for me if there is any performance impact on doing it in one-shot vs in incremental steps. The question is, should I expect any performance issues if I do a BigBang OpLog extension ? Because if I trigger it and I do have performance issues, it’s already too late to stop it.

4

@Okadan_Jep

The oplog will just grow larger, there is no preallocation of storage to the file. Just increase it to the desired size.

The general recommendation is to size for 72hrs of Oplog window. This allows for some downtime(like a weekend) of a member and allow it to resync.

Also update the configuration file to reflect the updated size, if a member has to undergo an initial sync the oplog will revert to the default or what is currently in the configuration file.

4.2.11 was released in November 2020 and had many patch releases until 4.2 went End of Life April 30 2023. I highly recommend investigating updating the database and applications using it.
https://www.mongodb.com/legal/support-policy/lifecycles

2 Likes
5

Thanks for the reply @chris . The upgrade is definitely next on the list.

6

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.