Replica Set Architecture

Majority as the unifying concept, voting membership, real failure scenarios, and specialized member roles

majority = floor(N/2) + 1the one threshold write concern, read concern, and elections all share
Up to 7 votersmore members beyond that must be non-voting
No majority = read-onlya partition with no majority side elects no primary anywhere
hidden/delayed/priority/votesdials on a normal secondary, not separate server types

1.Majority, the unifying concept

"Majority" means more than half of the replica set's voting members — a specific number computed from the set's configuration, not a vague idea of "most". It is the one number that write concern, elections, and majority read concern all key off, which is exactly why they interact safely with each other.

Key features

For N voting members, majority is floor(N/2) + 1 — 2 of 3, 3 of 5, 4 of 7
The same majority threshold governs write concern "majority", read concern "majority", and electing a new primary
A replica set with an even number of voting members can still compute a majority, but is more prone to a split where neither side has one — part of why odd counts are preferred
Because election and majority write concern share the same threshold, any two majorities within the same set are guaranteed to overlap by at least one member
This overlap guarantee is the structural reason a majority-committed write survives any single-primary failure

Command

text

majority = floor(votingMembers / 2) + 1

Majority = floor(votingMembers / 2) + 1, and the same threshold governs write concern, read concern, and elections — which is why any two majorities in the same set are guaranteed to overlap, and why that overlap is what protects a majority-committed write from being lost to a failover.

2.Voting members and election implications

Not every member of a replica set necessarily has a vote — a member can be configured with votes: 0, which excludes it from both voting in elections and ever becoming primary itself, while still holding a full copy of the data. The number of voting members is what "majority" is computed against.

Key features

MongoDB replica sets support up to 50 members total, but only up to 7 voting members
A member with votes: 0 cannot vote in an election and cannot become primary, but still replicates and can serve reads
The voting member count — not the total member count — is what majority is computed against
A larger voting member count means a stronger majority requirement (more members must agree), trading some availability for a higher bar before any write is considered safe
Adding non-voting members is a common way to add read capacity or geographic copies past the 7-voter cap without changing election dynamics

Command

text

rs.add({ host: "m8:27017", votes: 0, priority: 0 })

A member can hold a full data copy without being able to vote or become primary — the voting member count, not total member count, is what majority is computed against, and MongoDB caps voting members at 7.

3.Failure scenarios: primary loss and partitions

A single primary crash is the easy case — the remaining majority elects a new primary in seconds. A network partition is harder: it can split the set into two groups, and only the group holding a majority of voting members can elect a primary and keep accepting writes — the other side becomes read-only, unable to elect anyone.

Key features

Primary crash, majority of secondaries still reachable: a new primary is elected within the set's normal election time — the common, well-handled case
Network partition splitting a set roughly in half: only the side with a majority of voting members (if either does) can elect a primary; the minority side has no primary and serves reads only
A partition with no majority on either side (e.g. a 3-member set split 1-1-1 by a triple partition): neither side can elect, and the whole set is read-only until connectivity is restored
Losing a majority of voting members outright (not just a partition, an actual loss) leaves the set unable to elect until enough members are recovered or reconfigured
Multi-region deployments are especially exposed to partition scenarios — a majority of voting members should not all sit in a region that can be isolated by a single network event

Partition with a majority side vs. no majority side

5 members split 3-2

side with 3: has a majority, elects a primary
side with 2: no majority, read-only, cannot elect
the set keeps accepting writes, with reduced membership

3 members split 1-1-1 (triple partition)

no side has 2 of 3 — no majority anywhere
no primary can be elected on either side
the whole set is read-only until connectivity returns

Command

text

// After any failure: does any remaining group hold a majority of voting members? If yes, it elects. If no, the whole set has no primary.

After any failure, ask: does any remaining group hold a majority of voting members? That group elects and keeps working; every other group (including "no group at all") has no primary and is read-only until connectivity or membership is restored.

4.How concern settings interact with topology

Write concern "majority" and read preference are not abstract settings — their real behavior depends on how many voting members exist and where they are placed. The same w: "majority" write concern needs 2 acknowledgements in a 3-member set but 4 in a 7-member set, and a read preference targeting the "nearest" member behaves completely differently in a single-region set versus a globally distributed one.

Key features

w: "majority" scales with voting member count — more voters means more must agree, which raises both durability and the bar for availability during a partition
zone/region distribution of voting members determines which real-world failures (a data center outage, a region-level network event) the set can and cannot tolerate
A read preference like "nearest" only helps if there genuinely are geographically distributed members to be near — meaningless in a single-region topology
Adding non-voting members changes read capacity and geographic reach without changing the majority math a write concern relies on
A topology change (adding/removing voting members, changing priority) can silently change what "majority" requires — worth re-auditing concern settings after any such change, not just at initial setup

Command

text

// Re-derive: what does "majority" require, and where do "nearest"/"secondaryPreferred" reads actually land, for THIS topology specifically?

Write concern and read preference only mean something in the context of an actual topology — re-derive what "majority" requires and where reads actually land whenever voting member count or placement changes, not just once at initial setup.

5.Hidden, delayed, priority, and non-voting members

Beyond plain secondaries, a replica set member can be configured for a specific job: hidden (invisible to application read routing, used for dedicated backup/reporting), delayed (intentionally behind by a fixed window, a safety net against accidental data loss), priority-adjusted (more or less likely to be elected primary), or non-voting (holds data, no say in elections).

Key features

hidden: true — excluded from read preference routing and from the driver's member list the application sees, but still replicates and can vote
secondaryDelaySecs (formerly slaveDelay) — deliberately lags a fixed number of seconds behind the primary, useful as a recovery point for accidental writes/deletes
priority — a number (default 1) influencing how likely a member is to be elected primary; priority: 0 means the member can never become primary
votes: 0 — excluded from voting and the majority calculation, as covered earlier in this section
A delayed member is typically also configured hidden and non-voting, since it should not serve normal reads or participate in electing a primary while intentionally behind

Specialized member configurations

Specialized member configurations
Config	Effect	Typical use
hidden: true	invisible to read routing	dedicated backup/reporting member
secondaryDelaySecs: N	lags N seconds behind primary	recovery window for accidental writes
priority: 0	can never become primary	a member in a less-preferred location
priority: >1	more likely to be elected	preferring a specific, well-provisioned member
votes: 0	excluded from elections/majority	extra read/data copy without changing election math

Command

text

{ hidden: true, secondaryDelaySecs: <n>, priority: <n>, votes: 0 | 1 }

hidden, delayed, priority, and non-voting are dials on a normal secondary, not separate server types — combined (hidden + delayed + non-voting), they make a low-tech but effective recovery safety net against accidental data loss.

Spotted a mistake on this page? Tell us.

Read Sheet