For more details on MongoDB, please click LINK
1️⃣ What is an Arbiter in MongoDB?
An Arbiter is a special type of MongoDB replica‑set member that:
✅ Participates in elections
✅ Has a vote
❌ Does NOT store data
❌ Can NEVER become Primary
❌ Does NOT serve reads or writes
In short:
An Arbiter exists only to vote during primary elections.
2️⃣ Why does MongoDB even need an Arbiter?
To answer this, we must first understand how MongoDB elects a Primary.
🔑 Core rule in MongoDB elections (VERY IMPORTANT)
A Primary requires a MAJORITY of votes to be elected.
Majority is calculated as:
floor(total voting members / 2) + 1
3️⃣ What happens if you have ONLY ONE Secondary?
Scenario: Primary + Secondary (2 nodes)
|
Node |
Votes |
|
Primary |
1 |
|
Secondary |
1 |
|
Total votes |
2 |
|
Majority needed |
2 |
✅ Normal operation
- Primary is up → everything works
❌ Primary goes down
Now only 1 node is alive:
|
Alive votes |
Needed for majority |
|
1 |
2 |
🚫 No majority → no election → NO PRIMARY
🚨 Result: CLUSTER IS DOWN
Even though the secondary has the data, MongoDB refuses to promote it.
Why?
➡️ To avoid split‑brain scenarios
➡️ To protect data consistency
4️⃣ What is a Split‑Brain problem? (Why MongoDB is strict)
Imagine this:
- Network issue isolates Primary
- Secondary thinks Primary is dead
- Both nodes promote themselves
- Both accept writes
- Data diverges permanently
This is catastrophic data corruption.
MongoDB intentionally blocks elections without majority to prevent this.
✅ No majority = no primary = safety over availability
5️⃣ How does an Arbiter solve this?
Now add an Arbiter.
✅ Primary + Secondary + Arbiter (3 voting members)
|
Node |
Stores Data |
Votes |
|
Primary |
✅ |
✅ |
|
Secondary |
✅ |
✅ |
|
Arbiter |
❌ |
✅ |
|
Total votes |
3 |
|
|
Majority needed |
2 |
✅ Primary failure scenario
Primary goes down:
|
Remaining nodes |
Votes |
|
Secondary |
1 |
|
Arbiter |
1 |
|
Total |
2 ✅ |
🎉 Majority achieved → Secondary becomes PRIMARY
✅ That’s why Arbiter exists
The Arbiter exists to break election deadlocks when you have only two data‑bearing nodes.
6️⃣ Why not just allow a single secondary to take over?
This is the key design philosophy question.
MongoDB deliberately does NOT allow this because:
|
Reason |
Explanation |
|
Split‑brain risk |
Network partition could cause dual primaries |
|
Data safety > uptime |
MongoDB prioritizes data correctness |
|
Election fairness |
Requires quorum confirmation |
|
Predictable behavior |
Same rules apply everywhere |
Allowing a single node to promote itself would trade consistency for convenience.
MongoDB chooses consistency and correctness.
7️⃣ So what exactly does the Arbiter contribute?
✅ What Arbiter gives you
- ✅ Majority voting
- ✅ Automatic failover
- ✅ Low resource usage
- ✅ No extra storage cost
❌ What Arbiter does NOT give
- ❌ No data redundancy
- ❌ No backup protection
- ❌ No performance improvement
- ❌ No read scaling
8️⃣ Why Arbiter is considered a compromise (very important)
A Primary‑Secondary‑Arbiter (PSA) set:
✅ Solves election quorum
❌ Does NOT solve data loss risk
If any data‑bearing node fails, you still have only one copy of data left.
That’s why MongoDB says:
✅ PSA is acceptable
❌ PSA is NOT ideal for production‑critical systems
9️⃣ Best practice comparison
|
Topology |
High Availability |
Data Safety |
Recommendation |
|
Primary + Secondary |
❌ |
✅ |
❌ Not HA |
|
Primary + Secondary + Arbiter |
✅ |
⚠️ Limited |
✅ Small / cost‑limited setups |
|
3 Data Nodes |
✅✅ |
✅✅ |
✅✅ BEST PRACTICE |
|
5 Data Nodes |
✅✅✅ |
✅✅✅ |
Enterprise‑grade |
🔟 Clear final answer (you can quote this)
An Arbiter is needed in MongoDB when you have only two data‑bearing nodes because MongoDB requires a majority of votes to elect a primary. With only one secondary, there is no majority after primary failure, which stops elections to prevent split‑brain and data corruption. The Arbiter provides an extra vote without storing data, allowing automatic failover while maintaining election safety. A setup with only primary and one secondary is therefore not highly available and cannot fail over automatically.
✅ One‑line memory trick
MongoDB cares more about data correctness than uptime — Arbiter exists to preserve majority without extra data copies.