The oplog (operations log) is a capped MongoDB collection that keeps an ordered history of logical writes. It enables replication: a primary records operations, streams them to secondaries, and those nodes apply them asynchronously. Each replica-set member keeps an oplog copy in local.oplog.rs. section 9.1.3
Only successful operations that change data produce entries. A successful insertOne() creates an entry; insertMany() creates one for each document inserted. Failed inserts do not appear. Recorded operations are idempotent: applying one more than once has the same outcome as applying it once. section 4.2 section 9.1.3
Listing 9.3 A single document from the oplog collection
{
op: 'd',
ns: ' sample_mflix.sessions',
ui: new UUID("99f8f10f-e144-4419-a543-da211dd1a2de"),
o: { _id: ObjectId("65b1a0a4edf7e1f8d9ccc396") },
ts: Timestamp({ t: 1710267182, i: 5 }),
t: Long("38"),
v: Long("2"),
wall: ISODate("2024-03-12T18:13:02.838Z")
},
The deletion entry shows the operation type (op: 'd'), collection namespace (ns), deleted document’s _id (o), and ordering and timing metadata (ts and wall). section 9.1.3
Two commands help assess whether the log and secondaries are keeping pace:
- Run db.getReplicationInfo() to inspect configured and used log size and the timestamps covered by the oplog. section 9.1.3
- Run db.printSecondaryReplicationInfo() to inspect each secondary’s syncedTo time and reported replication lag. section 9.1.3
For application-facing change notifications, distinguish the oplog from change streams: change streams provide ordered, resumable notifications with access control and aggregation-pipeline integration, rather than requiring oplog tailing. section 9.6
