MongoDB replica sets provide automatic failover and data redundancy. This guide covers day-to-day operational tasks: adding/removing members, triggering elections, and diagnosing replication lag.
Replica Set Overview
PRIMARY ──► SECONDARY1
└─► SECONDARY2 (hidden: true for backups)Check Replica Set Status
rs.status()
rs.printReplicationInfo() // lag on primary
rs.printSecondaryReplicationInfo() // lag on each secondaryAdd a New Member
rs.add({ host: "mongo3:27017", priority: 1, votes: 1 })
// Add a hidden member for backups (no reads, no votes for primary)
rs.add({ host: "mongo-backup:27017", hidden: true, priority: 0 })Remove a Member
rs.remove("mongo3:27017")Force an Election (Step Down Primary)
// Step down primary for 60 seconds, triggering election
rs.stepDown(60)rs.stepDown() causes a brief write outage while the new primary is elected (typically < 12 seconds). Plan for application retry logic.Diagnosing Replication Lag
// Check oplog window on primary
db.getReplicationInfo()
// Check each member's lag
rs.status().members.forEach(m => {
if (m.optime) print(m.name, m.optimeDate)
})Oplog Size — Increase for High-Write Workloads
// Check current oplog size
db.printReplicationInfo()
// Resize oplog (MongoDB 4.4+)
db.adminCommand({ replSetResizeOplog: 1, size: 51200 }) // 50 GBRead Preference for Secondaries
// Allow reading from secondaries in mongosh
db.getMongo().setReadPref('secondaryPreferred')
// Connection string
// mongodb://host1,host2,host3/mydb?replicaSet=rs0&readPreference=secondaryPreferredKey Takeaways
- Use
rs.printSecondaryReplicationInfo()to spot lagging members immediately - Hidden members with
priority: 0are ideal for backup workloads - Increase oplog size proactively on high-write clusters to maintain recovery windows
- Always have an odd number of voting members to prevent ties in elections
JusDB Can Help
MongoDB replica set operations require expertise to do safely in production. JusDB's NoSQL specialists can help you optimize your replica set configuration.