MongoDB Replica Set High Availability

📋 What This Demo Shows

▼

🍃 MongoDB Replica Set

MongoDB replica set with Primary/Secondary roles and automatic elections
Real-time data replication via oplog
Intelligent leader election (majority voting required)
Read scaling across secondary members
Retryable writes and reads for automatic resilience
Sub-10 second failover with zero data loss
Prevents split-brain with majority consensus

🗄️ Traditional Database Clustering

Complex master-slave or active-passive setup
Manual failover procedures or expensive clustering
Potential split-brain scenarios
Application-level connection management
Minutes to hours of downtime during failures

🎯 Key Learning Points

✅ Automatic Failover

See how elections happen and new primaries emerge

✅ Data Protection

Watch real-time replication prevent data loss

✅ Read Scaling

Experience how reads distribute across replicas

✅ Recovery Process

Observe automatic member recovery and sync

✅ Majority Voting

Learn how MongoDB prevents split-brain scenarios

✅ No Primary State

See what happens when majority is lost

✅ Retryable Operations

Watch automatic retries handle transient failures

✅ Driver Resilience

See how apps stay unaware of infrastructure issues

⚙️ MongoDB Node Priority Configuration for 2-Node Quorum Scenarios

Customer Concern: "What happens when a primary fails and only 2 nodes remain? Won't MongoDB become read-only?"

🔧 Priority-Based Election Configuration

MongoDB maintains write availability through strategic priority settings and proper replica set sizing with data-bearing nodes:

Scenario 1: 3-Node Standard Replica Set

Node A (Primary)
Priority: 2

Node B (Secondary)
Priority: 1

Node C (Secondary)
Priority: 1

Result: If primary fails, Node B or C can become primary with majority vote (2/3 majority maintained)

Scenario 2: Data-Bearing Priority Config

Node A (Primary)
Priority: 3

Node B (Secondary)
Priority: 2

Node C (Secondary)
Priority: 1

Configuration Command:

rs.reconfig({..., members: [{..., priority: 3}, {..., priority: 2}, {..., priority: 1}]})

Result: Node A preferred as primary, but B can take over if A fails and majority exists

🎯 Reality Check: When MongoDB Stays Available

Majority Rule: With proper configuration, 2 out of 3 nodes can maintain write availability
Data-Bearing Nodes: All nodes store data and can serve reads, providing better resource utilization
Priority Weighting: Higher priority nodes become primary when available, ensuring predictable failover
No Single Points: Multiple nodes can serve as primary, unlike single-master systems

⚠️ True 2-Node Limitation

MongoDB intentionally becomes read-only in true 2-node scenarios to prevent split-brain. This is a feature, not a limitation - it ensures data consistency over availability when network partitions occur.

Best Practice: Deploy with 3+ data-bearing nodes for optimal availability and resource utilization.

🐘 PostgreSQL WAL-Based High Availability Comparison

PostgreSQL achieves high availability through Write-Ahead Logging (WAL) replication, similar to systems like Aurora and AlloyDB:

PostgreSQL Streaming Replication

Primary Server
WAL Writer

→ WAL Stream →

Standby Server
WAL Receiver

Failure Scenario Walkthrough:

1. Primary Failure Detection:

• Connection manager (pgpool/HAProxy) detects primary failure

• Application connections start failing

2. Manual Failover Process:

• DBA manually promotes standby: pg_promote()

• Or automatic with tools like Patroni/repmgr

3. Application Reconnection:

• Connection string updates required

• Load balancer reconfiguration

• Application restart may be needed

⚠️ PostgreSQL HA Limitations:

Manual Intervention: Requires DBA action or complex orchestration tools
Single Point of Failure: Only one primary can accept writes
Application Awareness: Apps must handle connection failures and reconnects
Split-Brain Risk: Without proper fencing, multiple primaries possible
Failover Time: Typically 30-60 seconds minimum for detection + promotion

MongoDB Automatic Failover Advantage

Automatic Detection:
Heartbeat failure (10s)

↓

Automatic Election:
Priority-based voting (2-3s)

↓

Automatic Recovery:
New primary ready (~15s total)

✅ MongoDB HA Advantages:

Zero Manual Intervention: Fully automated failover process
Driver Intelligence: Applications automatically discover new primary
Sub-15 Second Recovery: Typical failover in under 15 seconds
Built-in Split-Brain Prevention: Majority voting prevents dual primaries
Transparent to Apps: Retryable writes handle transient failures

🏆 Real-World Impact Comparison

Aspect	MongoDB Replica Sets	PostgreSQL + WAL
Failover Time	10-15 seconds (automatic)	30-60+ seconds (manual/scripted)
DBA Intervention	None required	Manual promotion or complex tooling
Application Changes	None (driver handles automatically)	Connection handling, retries
Split-Brain Prevention	Built-in majority consensus	Requires fencing mechanisms

🔄 MongoDB Replica Set High Availability

🛡️ Why This Matters: The Zero-Downtime Promise