Replica Set Configuration, Elections, and Failover
What this domain covers
Replica Set Configuration, Elections, and Failover tests your ability to initiate and reconfigure sets, reason about election outcomes, and choose write and read semantics that survive failover.
Core rules
- MongoDB uses a Raft-like election protocol. A candidate needs a majority of votes from voting members. The primary must be able to see a majority to remain primary.
- Priorities influence elections; priority 0 members cannot become primary. Hidden and delayed members must have priority 0. Arbiters vote but hold no data.
- Majority write concern acknowledges after a majority of voting members have applied the write. With three voting members, that is two. Write concern 1 is fast but can roll back on failover.
- Read preference includes primary, primaryPreferred, secondary, secondaryPreferred, and nearest. Secondary reads may return stale data and are not monotonic unless you use causal consistency.
- Reconfiguring uses rs.add(), rs.remove(), and rs.reconfig(). Use rs.conf() to inspect and rs.status() to see health.
Worked example
A five-member set has priorities 5, 2, 1, 0, 0. Majority is three. If the priority-5 primary is partitioned with only one peer, it sees two of five members and steps down. The other three elect the priority-2 member. With majority write concern, writes need three acknowledgements. A priority-0 member can never become primary even if it has the freshest data.
Traps
Thinking priority 0 can be primary; assuming arbiters can serve reads; using write concern 1 for critical writes; adding members by IP when hostnames are used; and forgetting that elections need a majority, so a two-node set cannot elect after one failure.