🔁 Replica Sets

Answer:

A Replica Set is a group of MongoDB instances that maintain the same dataset. It consists of:

• Primary Node: Receives all write operations
• Secondary Nodes: Maintain copies of primary's data through replication
• Arbiter (Optional): Participates in elections but doesn't hold data

High Availability Mechanism:

• Automatic failover: If primary fails, secondaries elect a new primary (typically 10-12 seconds)
• Data redundancy: Multiple copies prevent data loss
• Continuous replication: Secondaries sync data asynchronously
• Self-healing: Failed nodes automatically rejoin when recovered

Answer:

Failover Process (Step-by-Step):

1. Detection (2s): Secondaries detect primary failure through missed heartbeats (sent every 2 seconds)
2. Election Initiation (1-2s): Secondaries that can see a majority of members call for an election
3. Voting (5-8s): Members vote for the most up-to-date secondary. A candidate needs majority votes to win
4. New Primary (Total ~10s): Winning secondary becomes primary and starts accepting writes
5. Application Reconnection: MongoDB drivers automatically reconnect to the new primary

Key Points:

• Total downtime: 10-12 seconds (typical)
• No data loss if using appropriate write concerns
• Completely automatic - no manual intervention needed

Answer:

An Arbiter is a lightweight member of a replica set with these characteristics:

• Does not hold data: Only participates in elections
• Voting only: Provides a vote in elections to maintain odd number of voters
• Low resource usage: Minimal CPU/memory/disk requirements
• Tie-breaker: Prevents split-brain scenarios in 2-node setups

When to use:

• When you have even number of data-bearing nodes (e.g., 2 or 4)
• To maintain odd number of voters without the cost of full secondary
• Example: 2 data nodes + 1 arbiter = 3 voters (odd number)

Best Practice: For production, prefer using actual secondaries instead of arbiters when possible for better redundancy.

Answer:

Replication Lag: The time delay between when data is written to primary and when it's replicated to secondaries.

Typical Values:

• Normal: 100-500ms
• Warning: > 1 second
• Critical: > 10 seconds

Monitoring Methods:

1. rs.status(): Check "optimeDate" difference between primary and secondaries
2. rs.printReplicationInfo(): Shows oplog size and coverage
3. rs.printSecondaryReplicationInfo(): Detailed lag info for each secondary
4. MongoDB Atlas: Built-in monitoring dashboards
5. Third-party tools: Datadog, New Relic, Prometheus

Causes of High Lag:

• Network latency between nodes
• Heavy write load on primary
• Slow disk I/O on secondaries
• Secondary handling too many reads

Answer:

Write Concern: Level of acknowledgment requested from MongoDB for write operations.

Common Write Concerns:

• w: 1 - Acknowledged by primary only (fastest, less safe)
• w: "majority" - Acknowledged by majority of nodes (recommended for production)
• w: <number> - Acknowledged by specific number of nodes
• j: true - Wait for journal commit (durability)

// Example
db.orders.insertOne(
  { orderId: 123, total: 599 },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
)

Read Preference: Where to route read operations.

• primary - Read from primary only (default, most consistent)
• primaryPreferred - Primary if available, else secondary
• secondary - Read from secondary only
• secondaryPreferred - Secondary if available, else primary
• nearest - Read from nearest node (lowest latency)

// Example
db.products.find().readPref("secondary")

Answer:

Minimum: 3 nodes (1 Primary + 2 Secondaries)

Why 3?

• Majority for elections: Need majority (2 out of 3) to elect new primary
• Fault tolerance: Can survive 1 node failure and still maintain quorum
• Data redundancy: 3 copies of data protect against loss
• Odd number: Prevents split-brain scenarios

Production Recommendations:

• Startup/Small: 3 nodes
• Medium/Production: 5 nodes (can survive 2 failures)
• Critical/Enterprise: 7 nodes across multiple regions

Important: Always use odd number of voting members (3, 5, 7) to ensure clear majority in elections.

Answer:

Common Causes & Solutions:

1. Check Oplog Coverage:
   • Use rs.printReplicationInfo() on primary
   • If secondary is behind oplog window, it needs initial sync
   • Solution: Increase oplog size or resync from backup
2. Network Issues:
   • Check connectivity between secondary and primary
   • Verify firewall rules and network latency
   • Check for packet loss or timeouts
3. Disk Space:
   • Check if secondary has sufficient disk space
   • Monitor I/O performance
4. Resource Constraints:
   • Check CPU/Memory usage
   • Look for long-running operations

Troubleshooting Steps:

# 1. Check status
rs.status()

# 2. Check logs
db.adminCommand({getLog: "global"})

# 3. Check replication info
rs.printSecondaryReplicationInfo()

# 4. If needed, resync
# Stop secondary, delete data, restart
# It will automatically perform initial sync