Requirements

Delayed members:

• Must be priority 0 members. Set the priority to 0 to prevent a delayed member from becoming primary.
• Should be hidden members. Always prevent applications from seeing and querying delayed members.
• do vote in elections for primary, if members[n].votes is set to 1.

Behavior

Delayed members copy and apply operations from the source oplog on a delay. When choosing the amount of delay, consider that the amount of delay:

• must be equal to or greater than your expected maintenance window durations.
• must be smaller than the capacity of the oplog. For more information on oplog size, see Oplog Size.

Write Concern

Delayed replica set members can acknowledge write operations issued with w: <number>. For write operations isued with w : "majority", however, delayed members must also be voting members (i.e. members[n].votes greater than 0) to acknowledge the "majority" write operation. Non-voting replica set members (i.e. members[n].votes is 0) cannot contribute to acknowledging write operations with majority write concern.

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.

Sharding

In sharded clusters, delayed members have limited utility when the balancer is enabled. Because delayed members replicate chunk migrations with a delay, the state of delayed members in a sharded cluster are not useful for recovering to a previous state of the sharded cluster if any migrations occur during the delay window.