Replica Set Members: Primary, Secondary, Arbiter

A replica set is a group of MongoDB servers that all hold the same data, providing high availability and redundancy. If one server fails, another automatically takes over. A typical replica set has three or more members: at least one primary, one or more secondaries, and optionally an arbiter.

The primary is the only member that accepts write operations. All clients send inserts, updates, and deletes to the primary. It records every write operation in a special log called the oplog (operations log), which secondaries then read to stay in sync.

A secondary replicates data from the primary by continuously tailing the primary's oplog and applying the same operations to its own copy of the data. Secondaries can serve read queries (with the right read preference) and will take over as primary if the current primary becomes unavailable.

The oplog (operations log) is a special capped collection stored in the local database on every replica set member. Every write to the primary is appended to the oplog. Secondaries read the oplog and replay each entry in order, keeping their data identical to the primary. The oplog's size determines how far behind a secondary can fall before needing a full resync.

An arbiter is a lightweight replica set member that holds no data. Its sole purpose is to participate in elections by casting a vote when a new primary needs to be chosen. Arbiters are used in even-member sets (e.g., two data-bearing members) to ensure a majority can always be reached without the cost of a third full data node.

Each replica set member has a vote (0 or 1). A primary is elected by majority vote. With 3 members (each with 1 vote), a majority is 2. If the primary goes down, the remaining two members hold an election and the one with the most up-to-date oplog typically wins. Elections complete in seconds under normal network conditions.

Each member has a priority value (default 1). A member with higher priority is preferred as primary in elections. Setting priority to 0 prevents a member from ever becoming primary — useful for secondaries in distant data centers that should serve local reads but not take writes from the primary region.

Hidden secondaries (priority 0, hidden: true) are invisible to drivers and used only for backups or analytics without affecting the primary election pool. Delayed secondaries intentionally lag behind the primary by a configured number of seconds, providing a rolling recovery window in case of accidental data corruption.

Replication lag is the delay between when a write is committed on the primary and when it appears on a secondary. High lag means secondaries serve stale data. You can monitor lag with rs.printSecondaryReplicationInfo() or by comparing the oplog timestamps between members. Atlas provides built-in lag alerts.

rs.status() returns the full health snapshot of the replica set. Key fields to inspect: stateStr (PRIMARY / SECONDARY / ARBITER / DOWN), optimeDate (last applied oplog entry), health (1 = healthy, 0 = unreachable), and lastHeartbeatMessage for error details on troubled members.

When a client writes a document, the flow is: 1) Driver sends write to the primary. 2) Primary applies the write to WiredTiger storage. 3) Primary appends the operation to its oplog. 4) Secondaries pull the oplog entry and apply it. 5) Primary acknowledges the client according to the configured writeConcern.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: the primary accepts all writes and records them in the oplog, secondaries replicate from the oplog to maintain identical copies, and arbiters hold no data but cast votes in elections. Next up we explore how MongoDB automatically elects a new primary when the current one fails.