I have a ReplicaSet running fine once I ran rs.stepDown() and looking for rs.status() I get fine logs.

Here is one as evidence:

rsdev:SECONDARY> db.printSlaveReplicationInfo()
source: lab:27017
    syncedTo: Mon Jul 17 2017 09:20:52 GMT-0300 (BRT)
    0 secs (0 hrs) behind the primary 

I got one problem with my application that if I change the primary to the server X which used to be the secondary than I just can't use its oplog as I was when using server Y as primary.

I know that when I have a new member in the ReplicaSet it may will have the dataSet size smaller than its primary due to its age, delete, insert and so on.

But should its oplog size be different between them?

rsdev:PRIMARY> db.getReplicationInfo().usedMB

rsdev:SECONDARY>  db.getReplicationInfo().usedMB

This secondary server is the new one which I get into problem if become primary.

Both using wiredTiger storage.

2 Answers 2


If you haven't defined in config (file or parameter; replication.oplogSizeMB) what size of opLog you wanted when node was initialized, it is automatically set base on free space on data disk. In wireTiger it's 5% of free disk space (990MB-50GB).

You can change that oplog size if you want, but after that you need to wait until it's full.


As you said that you have done once rs.stepDown in replica set, As per MongoDB BOL rs.stepDown() is New in version 3.0. Before stepping down, rs.stepDown() will attempt to terminate long running user operations that would block the primary from stepping down, such as an index build, a write operation or a map-reduce job.

To avoid rollbacks, rs.stepDown(), by default, only steps down the primary if an electable secondary is completely caught up with the primary. The command will wait up to either 10 seconds or the secondaryCatchUpPeriodSecs for a secondary to catch up.

Note: rs.stepDown() blocks all writes to the primary while it runs.

The oplog (operations log) is a special capped collection that keeps a rolling record of all operations that modify the data stored in your databases. MongoDB applies database operations on the primary and then records the operations on the primary’s oplog. The secondary members then copy and apply these operations in an asynchronous process. All replica set members contain a copy of the oplog, in the local.oplog.rs collection, which allows them to maintain the current state of the database.

When you start a replica set member for the first time, MongoDB creates an oplog of a default size For Unix and Windows systems for WiredTiger Storage Engine is

Default Oplog Size     Lower Bound  Upper Bound
5% of free disk space   990 MB       50 GB

For example, if an oplog is 5% of free disk space and fills up in 24 hours of operations, then secondaries can stop copying entries from the oplog for up to 24 hours without becoming too stale to continue replicating. However, most replica sets have much lower operation volumes, and their oplogs can hold much higher numbers of operations.

As rs.stepDown() method here

rs.stepDown(stepDownSecs, secondaryCatchUpPeriodSecs)

Before making the rs.stepDown you have to make sure that The method only steps down the primary if an electable secondary is up-to-date with the primary, waiting up to 10 seconds, by default, for a secondary to catch up.

Note : rs.stepDown() provides a wrapper around the command replSetStepDown.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.