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.
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
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.
rs.stepDown() method here
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.
rs.stepDown() provides a wrapper around the command