Replication keeps copies of MongoDB data on multiple server instances. A primary handles writes and copies operations to secondary members of a replica set. Those copies support availability and disaster recovery; reads can also be distributed to reduce load on the primary. Writes still go through that primary, so replication does not remove a write bottleneck. section 9.0
The oplog keeps the copies moving:
- The primary executes a successful data-changing write and records it in its capped operations log, or oplog. section 9.1.3
- The primary streams the operation to secondaries, which apply it asynchronously. Each replica-set member maintains an oplog copy in local.oplog.rs. section 9.1.3
- Oplog operations are idempotent: applying one more than once produces the same result as applying it once. section 9.1.3
Read an oplog entry
A deletion entry for sample_mflix.sessions uses op: 'd' and identifies the deleted document in o._id. Its ts records the operation timestamp; t identifies the replica-set election term. An insert entry instead uses op: 'i' and includes the inserted document in o. 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")
},
Inspect a deletion’s operation type, namespace, document identifier, and timestamps in a single oplog document. section 9.1.3
To check replication, run db.getReplicationInfo() for oplog size and the time span it covers. Run db.printSecondaryReplicationInfo() to see when each secondary last synchronized and how far it trails the primary. The sample output reports one secondary at zero lag and another ten seconds behind. section 9.1.3
Listing 9.6 Output of the db.printSecondaryReplicationInfo() command
db.printSecondaryReplicationInfo()
source: ac-5dhjxpf-shard-00-00.fpomkke.mongodb.net:27017
{
syncedTo: 'Wed Mar 27 2024 18:21:52 GMT+0000
➥(Coordinated Universal Time)',
replLag: '0 secs (0 hrs) behind the primary '
}
---
source: ac-5dhjxpf-shard-00-01.fpomkke.mongodb.net:27017
{
syncedTo: 'Wed Mar 27 2024 18:21:53 GMT+0000
➥(Coordinated Universal Time)',
replLag: '10 secs (0 hrs) behind the primary '
}
Compare per-secondary syncedTo and replLag values when checking whether copies have caught up. section 9.1.3
Replication and sharding solve different problems. Sharding partitions data across servers to spread work, including writes; replication preserves copies for availability. Replicating each shard helps keep its data accessible during server downtime and supports rolling updates. MongoDB Atlas provides replication by default and manages its setup, while sharding is an optional horizontal-scaling choice. section 9.0
