What is the oplog in MongoDB and what role does it play in replication?
Learn what the MongoDB oplog is, how the capped operations log lets secondaries replay writes, and why it powers replication, change streams and failover.
Expected Interview Answer
The oplog (operations log) is a special capped collection in MongoDB that records every write operation the primary applies, so secondaries can replay those operations and stay in sync.
It lives in the local database as local.oplog.rs and stores each change as an idempotent entry keyed by a timestamp. Secondaries continuously tail the primary's oplog and apply the same operations in order, which is how a replica set keeps identical copies of the data. Because the oplog is capped (fixed size), old entries are overwritten; if a secondary falls too far behind and the needed entries have rolled off, it can no longer catch up incrementally and requires a full resync.
- Enables secondaries to replay writes and stay consistent
- Idempotent entries make replay safe on retries
- Powers change streams and downstream data pipelines
- Supports point-in-time recovery within its window
- Allows automatic failover with minimal data loss
AI Mentor Explanation
The oplog is like the ball-by-ball commentary logbook of a match. The main scorer at the primary ground writes down every delivery in order, and reserve scorers at other grounds copy each entry to keep identical books. Because each line is precise, anyone replaying it reconstructs the exact innings. But the logbook has fixed pages, so if a reserve scorer arrives too late the earliest overs are gone and they must copy the whole book afresh.
Step-by-Step Explanation
Step 1
Primary applies a write
The primary executes an insert, update or delete and commits it to its data files.
Step 2
Record to oplog
It appends an idempotent entry describing the change to local.oplog.rs, tagged with a timestamp.
Step 3
Secondaries tail the oplog
Each secondary continuously reads new oplog entries from the primary (or a sync source).
Step 4
Replay in order
Secondaries apply the operations in the same sequence, reproducing the primary's state.
Step 5
Handle the capped window
If a secondary lags past the oplog's oldest entry, it can no longer tail and must do a full initial sync.
What Interviewer Expects
- Knows the oplog is a capped collection in the local database
- Understands idempotency of oplog entries
- Can explain how secondaries tail and replay operations
- Aware of oplog sizing and replication lag consequences
- Connects the oplog to change streams and failover
Common Mistakes
- Confusing the oplog with the journal (write-ahead log)
- Saying the oplog stores queries rather than resulting operations
- Thinking the oplog grows unbounded instead of being capped
- Not knowing that lagging past the window forces a full resync
Best Answer (HR Friendly)
“The oplog is MongoDB's running log of every change made on the main copy of the data. Other copies read this log and apply the same changes, which keeps all the servers in sync and lets one take over automatically if the main one fails.”
Code Example
// Switch to the local database that holds the oplog
use local
// View the most recent operations
db.oplog.rs.find().sort({ $natural: -1 }).limit(5)
// Check the configured oplog size and time window
rs.printReplicationInfo()
// Resize the oplog to 4 GB (run on each member)
db.adminCommand({ replSetResizeOplog: 1, size: 4096 })Follow-up Questions
- What happens when a secondary's replication lag exceeds the oplog window?
- How do change streams build on top of the oplog?
- Why must oplog entries be idempotent?
- How would you size the oplog for a high-write workload?
MCQ Practice
1. In which database does the oplog reside?
The oplog is stored as local.oplog.rs in the local database, which is not replicated as user data.
2. Why must oplog entries be idempotent?
Idempotency lets secondaries safely re-apply operations during retries or resync without corrupting data.
3. What happens if a secondary lags past the oldest oplog entry?
Because the oplog is capped, needed entries roll off and the secondary can no longer catch up incrementally, so it must resync fully.
Flash Cards
What is the oplog? — A capped collection (local.oplog.rs) recording every write on the primary so secondaries can replay them.
Why capped? — It has a fixed size; old entries are overwritten, bounding disk use but creating a replication window.
What tails the oplog? — Secondaries continuously read new entries from their sync source and apply them in order.
What builds on the oplog? — Change streams and downstream CDC pipelines consume oplog events.