- Replication >
- Replication Concepts >
- Replica Set High Availability >
- Replica Set Elections
Replica Set Elections¶
Replica sets use elections to determine which set member will become primary. Elections occur after initiating a replica set, and also any time the primary becomes unavailable. The primary is the only member in the set that can accept write operations. If a primary becomes unavailable, elections allow the set to recover normal operations without manual intervention. Elections are part of the failover process.
In the following three-member replica set, the primary is unavailable. One of the remaining secondaries holds an election to elect itself as a new primary.
Elections are essential for independent operation of a replica set; however, elections take time to complete. While an election is in process, the replica set has no primary and cannot accept writes and all remaining members become read-only. MongoDB avoids elections unless necessary.
If a majority of the replica set is inaccessible or unavailable to the current primary, the primary will step down and become a secondary. The replica set cannot accept writes after this occurs, but remaining members can continue to serve read queries if such queries are configured to run on secondaries.
Factors and Conditions that Affect Elections¶
Replication Election Protocol¶
New in version 3.2: MongoDB introduces a version 1 of the replication protocol (protocolVersion: 1) to reduce replica set failover time and accelerates the detection of multiple simultaneous primaries. New replica sets will, by default, use protocolVersion: 1. Previous versions of MongoDB use version 0 of the protocol.
Heartbeats¶
Replica set members send heartbeats (pings) to each other every two seconds. If a heartbeat does not return within 10 seconds, the other members mark the delinquent member as inaccessible.
Member Priority¶
After a replica set has a stable primary, the election algorithm will make a “best-effort” attempt to have the secondary with the highest priority available call an election. Higher priority secondaries call elections relatively sooner than lower priority secondaries; however, a lower priority node can still be elected as primary for brief periods of time, even if a higher priority secondary is available. Replica set members will continue to call elections until the highest priority available member becomes primary.
Members with a priority value of 0 cannot become primary and do not seek election. For details, see Priority 0 Replica Set Members.
Network Partitions¶
Network partitions affect the formation of a majority for an election. If a primary steps down and neither portion of the replica set has a majority the set will not elect a new primary. The replica set becomes read-only.
To avoid this situation, place a majority of instances in one data center and a minority of instances in any other data centers combined.
Non-Voting Members¶
Although non-voting members do not vote in elections, these members hold copies of the replica set’s data and can accept read operations from client applications.
Because a replica set can have up to 50 members, but only 7 voting members, non-voting members allow a replica set to have more than seven members.
For instance, the following nine-member replica set has seven voting members and two non-voting members.
A non-voting member has a members[n].votes setting equal to 0 in its member configuration:
{
"_id" : <num>
"host" : <hostname:port>,
"votes" : 0
}
Important
Do not alter the number of votes to control which members will become primary. Instead, modify the members[n].priority option. Only alter the number of votes in exceptional cases. For example, to permit more than seven members.
To configure a non-voting member, see Configure Non-Voting Replica Set Member.
Thank you for your feedback!
We're sorry! You can Report a Problem to help us improve this page.