Выборы и автоматическое переключение при отказе

Automatic failover is the ability of a MongoDB replica set to recover from a primary node failure without human intervention. When the primary becomes unreachable, the remaining members automatically elect a new primary — typically within 10 to 30 seconds — so that applications experience only a brief pause rather than a full outage.

Replica set members continuously exchange heartbeat messages every 2 seconds. If a member does not receive a heartbeat response within electionTimeoutMillis (default 10 seconds), it marks the silent member as inaccessible. If the missing member is the primary, the remaining eligible members begin an election.

An election is triggered in three scenarios: 1) the primary becomes unreachable (network partition or crash), 2) a user manually steps down the primary with rs.stepDown(), or 3) a secondary with higher priority joins and the current primary has lower priority. Only members with votes: 1 and priority > 0 are eligible to become the new primary.

MongoDB elections use a protocol inspired by Raft consensus. Each candidate increments its term counter and solicits votes from other members. A candidate wins if it receives votes from a majority of the voting members. The candidate with the most up-to-date oplog (highest optime) is preferred — this prevents data loss by ensuring the new primary has seen all acknowledged writes.

A candidate needs votes from more than half of all voting members (not just the ones currently reachable). In a 3-member set with 3 votes, a majority is 2. This means that if 2 members go down simultaneously, the surviving member cannot elect itself — it would be operating on stale data with no way to know if the other two members have newer writes.

The election unfolds as follows: 1) A secondary notices the primary is gone after the timeout. 2) It transitions to CANDIDATE state. 3) It sends RequestVote messages to all other members. 4) Members grant votes if the candidate's oplog is at least as current as theirs and they haven't already voted. 5) The winner transitions to PRIMARY and begins accepting writes.

During the election window (typically a few seconds), writes are refused because there is no primary. The MongoDB driver buffers write operations and retries them once a new primary is elected. With retryable writes enabled (the default in modern drivers), transient election errors are transparently retried once.

When multiple candidates are equally up to date, priority breaks the tie — the member with the highest priority wins. If a secondary with higher priority rejoins after being offline, it will trigger a new election to take the primary role. Setting priority to 0 permanently excludes a member from ever becoming primary.

In a network partition, members on one side of the split cannot communicate with the other. The side with the majority of votes can elect a primary; the minority side enters a read-only state. This prevents a split-brain scenario where two members simultaneously believe they are primary and accept conflicting writes.

You can monitor elections and failovers by examining the MongoDB log or querying the system.replset config. Atlas provides real-time alerts for election events. In your application logs, you will see MongoNotPrimaryError or MongoNetworkError spikes during an election — retryable writes handle these automatically.

To minimise failover time: 1) Keep replica sets with odd member counts (3 or 5) to avoid needing arbiters. 2) Use a majority write concern to ensure the elected secondary has all committed writes. 3) Minimise oplog lag by providing sufficient oplog size. 4) Place replica set members in the same region for low-latency heartbeats.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: heartbeats detect primary failure within electionTimeoutMillis (10 s default), the candidate with the most current oplog and highest priority wins the election, and retryable writes let applications survive brief election windows transparently. Next up we explore write concerns and how to control the durability of writes across the replica set.