Delayed Replica Set Members
Delayed members contain copies of a replica set’s data set. However, a delayed member’s data set reflects an earlier, or delayed, state of the set. For example, if the current time is 09:52 and a member has a delay of an hour, the delayed member has no operation more recent than 08:52.
Because delayed members are a “rolling backup” or a running “historical” snapshot of the data set, they may help you recover from various kinds of human error. For example, a delayed member can make it possible to recover from unsuccessful application upgrades and operator errors including dropped databases and collections.
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.
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.
0) cannot contribute to acknowledging write operations with
majority write concern.
Delayed secondaries can return write acknowledgment no earlier than the configured
In the following 5-member replica set, the primary and all secondaries have copies of the data set. One member applies operations with a delay of 3600 seconds (one hour). This delayed member is also hidden and is a priority 0 member.