Replication keeps multiple copies of the same data on different mongod instances. If one server fails, another copy can keep the application running.
Main benefits: redundancy, high availability, automatic failover, better data availability, disaster-recovery copies, and—when configured—optional read distribution.
Replication = multiple live copies of the same data
Replica set → primary (writes) + secondaries (replicate)
Oplog → log of operations secondaries apply
Failover → election can choose a new primary
Not the same as a backup.A replica set is a group of mongod instances that maintain the same data set. At any time, one member is the primary; the others are secondaries.
The primary receives writes. Secondaries replicate changes from the primary so their data sets converge toward the same state.
Application
|
v
Primary
/ \
v v
Secondary Secondary| Reason | What it gives you |
|---|---|
| Server failure protection | Other members still hold the data |
| High availability | A new primary can be elected after failure |
| Multiple copies | Redundancy across machines or sites |
| Disaster recovery / reporting | Dedicated copies for special purposes |
| Geographic distribution | Data closer to users in more than one region |
| Optional read distribution | Some reads can target secondaries (may be stale) |
Replication is not a backup. Replication maintains additional current copies. Backups provide historical recovery points. You need both for a complete strategy.
Writes go to the primary. The primary records each change in its oplog. Secondaries read that oplog and apply the same operations asynchronously.
Application
|
v
Primary
|
v
Oplog
|
+----------+
| |
v v
Secondary SecondaryThe primary receives write operations, records changes in the oplog, and can serve reads. It may step down when needed. If it becomes unavailable, an election can select a new primary.
A secondary replicates from the primary and keeps its own copy of the data. It can serve reads when the client’s read preference allows it, and an eligible secondary can become primary through an election.
Because replication is asynchronous, a secondary may briefly lag behind the primary. Secondary reads can therefore return data that is not yet identical to the primary.
The oplog (operation log) is a special log of write operations on the primary. Secondaries use it as the source of truth for which changes to apply next.
Primary changes:
price: 100 → 120
↓
Oplog records operation
↓
Secondary reads oplog
↓
Secondary applies changeWrite data to Primary
Primary records the operation
Primary writes operation to oplog
Secondary reads oplog
Secondary applies operation
Repeat for future operationsInsert one product through the primary, then follow how secondaries catch up.
db.products.insertOne({
name: "Laptop",
price: 75000
})Application
↓
Primary
↓
Oplog
↓
Secondaryproducts.If the primary becomes unavailable long enough, eligible members hold an election to choose a new primary.
Before failure:
Primary
|
+-- Secondary
+-- Secondary
Primary fails
X
Secondary A
|
Election
|
New PrimaryBy default, electionTimeoutMillis is 10 seconds (MongoDB’s documented default). Network conditions and configuration affect how long an election actually takes—do not treat failover as instant.
Replication lag is the delay between an operation on the primary and the application of that operation on a secondary from the oplog.
Primary:
Insert Order #101
|
| replication delay
v
Secondary:
Insert Order #101rs.status()).Read preference controls which replica set member(s) a client uses for reads. The default is primary. Non-primary modes may return stale data because replication is asynchronous.
| Read Preference | Basic idea |
|---|---|
primary | Read from the primary (default) |
primaryPreferred | Prefer the primary; use a secondary if needed |
secondary | Read from secondary members only |
secondaryPreferred | Prefer a secondary; fall back to primary if needed |
nearest | Read from a suitable low-latency member (primary or secondary) |
Write concern controls the level of acknowledgment requested for a write operation. For most deployments, the default is w: "majority".
db.orders.insertOne(
{ orderId: 101, total: 500 },
{ writeConcern: { w: "majority" } }
)w: "majority", acknowledgment comes after a calculated majority of data-bearing voting members have durably recorded the change in their local oplog.| Concept | Controls |
|---|---|
| Read concern | Consistency / isolation level for reads |
| Write concern | How a write is acknowledged |
| Read preference | Which member receives the read |
Do not mix these up: preference chooses where to read; concern settings describe acknowledgment and consistency behavior.
Multi-document transactions are available on replica sets. Transactions that contain reads must use read preference primary, and all operations in a transaction route to the same member.
Replication and transactions are different features: replication copies data across members; transactions group multiple operations into one atomic unit.
Short mongosh-oriented examples. Run them against a replica set (standalone servers do not demonstrate failover or secondary reads).
db.products.insertOne({
name: "Laptop",
price: 75000
})Prefer secondaries for this session’s reads. Remember: data may be slightly behind the primary.
db.getMongo().setReadPref("secondaryPreferred")
db.products.find({ name: "Laptop" })setReadPref tells the client which members to prefer for reads.secondaryPreferred tries a secondary first, then the primary if needed.db.orders.insertOne(
{ orderId: 101, total: 500 },
{ writeConcern: { w: "majority" } }
)w: "majority" acknowledgment.Administrative command to inspect members, roles, and health.
rs.status()rs.status() reports replica set configuration and member state.PRIMARY vs SECONDARY.Common beginner mistakes around MongoDB replication.
Secondaries apply oplog entries later—not in lock-step with every primary write.
Do not assume a secondary always has the newest document. Prefer primary reads when freshness is required.
Live copies do not replace point-in-time backups for accidental deletes or corruption.
Default reads go to the primary. Secondary reads require an explicit non-primary read preference.
Read preference = which member. Write concern = write acknowledgment. Read concern = read consistency/isolation.
Default detection uses a 10s election timeout; network conditions can extend the window without a writable primary.
Secondary reads can help some workloads, but consistency, lag, and write amplification still matter. Scaling reads is a design choice, not free capacity.
| Idea | Practical tip |
|---|---|
| Extra work | Replication adds network and storage work as ops propagate |
| Oplog apply | Secondaries must read and apply oplog entries continuously |
| Lag | Monitor lag; heavy write bursts can increase it |
| Secondary reads | Can offload some reads—choose based on consistency needs, not speed alone |
| Write concern | Stronger acknowledgment can increase write latency |
| Concept | Remember |
|---|---|
| Replica set | Group of MongoDB instances maintaining the same data |
| Primary | Receives writes |
| Secondary | Replicates data from the primary |
| Oplog | Records operations for replication |
| Election | Selects a new primary when needed |
| Replication lag | Delay between primary and secondary application |
| Read preference | Controls where reads are directed |
| Write concern | Controls write acknowledgment |
| Read concern | Controls read consistency / isolation behavior |
One line: A replica set keeps the same data on multiple servers—writes hit the primary, secondaries follow the oplog, and elections restore a writable primary after failure.
Scale data across shards—each shard is typically a replica set.
11 people found this page helpful