Problem Statement
What are arbiter nodes in MongoDB replica sets and when should you use them?
Explanation
An arbiter is a special type of replica set member that participates in elections but does not hold data. Arbiters exist solely to provide an odd number of votes in elections, helping achieve majority consensus. They do not replicate data, do not serve reads, and require minimal resources.
Arbiters are useful when you have an even number of data-bearing members and need to break ties in elections. For example, in a two-data-center deployment with one member in each datacenter, adding an arbiter ensures you can elect a primary even if one datacenter becomes unavailable.
However, arbiters are generally not recommended for production deployments. It is better to use an additional data-bearing secondary instead. A third data-bearing member provides data redundancy and can serve reads, while an arbiter only provides voting without additional resilience.
If you must use an arbiter, place it in a third location separate from your data-bearing members. Never place an arbiter in the same failure domain as the primary or majority of secondaries, as this defeats its purpose of enabling elections during failures.
Arbiters should be used sparingly. The recommended approach is always to have an odd number of data-bearing members such as three or five, rather than using arbiters to supplement even-numbered configurations.
Code Solution
SolutionRead Only
// Add arbiter to replica set
rs.addArb("mongodb3.example.net:27017")
// Replica set with arbiter (not recommended)
// Primary: full data, accepts writes
// Secondary: full data, replicates
// Arbiter: no data, votes in elections
// Better approach: use data-bearing member
// Primary: full data, accepts writes
// Secondary 1: full data, replicates, can serve reads
// Secondary 2: full data, replicates, can serve reads
// Check arbiter status
rs.status().members.forEach(m => {
print(m.name + ": " + m.stateStr)
})