MongoDB Election Instability

Investigate frequent primary changes with replica set evidence. Continuously monitor election trends to expose availability risk.

2026-09-18 · 2 min read

Why this problem matters

Frequent elections can trigger connection rerouting and brief write interruptions. An election is not inherently a failure, but repetition can signal infrastructure instability.

How to diagnose it

Inspect the current primary, term, and member health through rs.status(). Correlate election times with network loss, process restarts, and resource pressure.

This output shows current state rather than complete election history. Historical analysis requires logs and time-series measurements.

const s = rs.status();
({set: s.set, term: s.term, members: s.members.map(m => ({name: m.name, state: m.stateStr, health: m.health}))})

A safe solution approach

Address connectivity and resource problems among voting members first. Change priority or vote configuration only after reviewing the topology design.

Why continuous monitoring matters

Continuous election-frequency monitoring separates isolated events from recurring instability. moon monitors with low overhead and routes alerts to Slack, PagerDuty, or webhooks.

Frequently asked questions

Does every primary change cause an application error?

No, correctly configured drivers can handle transient topology changes. Frequent changes still increase latency and availability risk.

How does moon help with this problem?

moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.