How does a replica set stay consistent? How does a backup restore to any exact point in time? Both answers point to the same place — the oplog. This post is about that often-overlooked, circular log that quietly holds up the entire high-availability story.
The oplog (operations log) lives in local.oplog.rs, and it's fundamentally a fixed-size capped collection — recording every write operation that has ever happened on this replica set. It isn't a "log file" in the traditional sense; it's an actual MongoDB collection that can be queried, subscribed to, and replicated.
There's a detail that's easy to overlook: operations recorded in the oplog are idempotent. Applying the same operation multiple times produces exactly the same result as applying it once — and that property is precisely what makes it safe for the whole replication mechanism to replay. As a side note, MongoDB's Change Streams feature is, at its core, also just subscribing to this same log.
Every write on the primary is recorded to the oplog first, then replicated asynchronously to each secondary. Internally, each secondary keeps a tailable cursor pointed at the oplog — continuously reading newly written operations, the way you'd follow a live feed, and replaying them locally. That "following" process has an inherent delay, which is what we call replication lag.
Because the oplog is a fixed-size capped collection, once it's full, new operations overwrite the oldest ones. The time span between the "oldest surviving entry" and the "most recent write" currently in the oplog is called the oplog window — and it determines just how far back this log can actually see.
Bigger isn't automatically better, and smaller isn't automatically easier — the size of this window directly decides whether two important things are even possible.
On the surface, the oplog window looks like a storage-tuning parameter. In practice, two things that matter a great deal for system reliability both rest on top of it.
If a secondary drops offline or falls significantly behind, it can catch up through normal incremental replication as long as the gap stays within the oplog window. Once it exceeds the window, the operations it needs have already been overwritten, and it's forced into a costly full resync (initial sync).
Point-in-time recovery works by taking a full snapshot and replaying the incremental oplog on top of it. If the segment of oplog the backup tool needs to replay has already been flushed out by the window, the closest point you can actually restore to will be far earlier than you assumed.
This is exactly why replication lag (oplog lag) is one of the core metrics WAP tracks continuously — whether the window is long enough, and whether the gap is widening, are signals that need constant watching, not something you discover only after a full resync has already been triggered.
The right oplog size depends on two numbers: the write volume generated per unit of time, and the worst-case scenario you want covered — how long a planned maintenance window runs, or how far apart your backup cycles are set. The window needs to cover at least the longest of these, with some safety margin on top. MongoDB supports resizing the oplog on the fly with replSetResizeOplog, with no replica set restart required — which means "start with a reasonable default, then recalculate once real usage patterns emerge" is a perfectly viable path.
You barely notice whether the oplog is configured well — until the day something breaks, and you find out exactly how much it mattered. Continuously tracking the window and the lag is something Whaleal Platform does every single day.