Replication - MongoDB in Action - page 166

idempotent—it can't matter how many times a given oplog entry is applied; the result
must always be the same. Other multidocument operations, like deletes, will exhibit
the same behavior. You're encouraged to try different operations and see how they
ultimately appear in the oplog.
To get some basic information about the oplog's current status, you can run the
shell's db.getReplicationInfo() method:

> db.getReplicationInfo()
{

"logSizeMB" : 50074.10546875,
"usedMB" : 302.123,
"timeDiff" : 294,
"timeDiffHours" : 0.08,
"tFirst" : "Thu Jun 16 2011 21:21:55 GMT-0400 (EDT)",
"tLast" : "Thu Jun 16 2011 21:26:49 GMT-0400 (EDT)",
"now" : "Thu Jun 16 2011 21:27:28 GMT-0400 (EDT)"

}
Here you see the timestamps of the first and last entries in this oplog. You can find
these oplog entries manually by using the $natural sort modifier. For example, the
following query fetches the latest entry: db.oplog.rs.find().sort({$natural: -1})
.limit(1)
The only important thing left to understand about replication is how the secondar-
ies keep track of their place in the oplog. The answer lies in the fact that secondaries
also keep an oplog. This is a significant improvement upon master-slave replication,
so it's worth taking a moment to explore the rationale.
Imagine you issue a write to the primary node of a replica set. What happens next?
First, the write is recorded and then added to the primary's oplog. Meanwhile, all sec-
ondaries have their own oplogs that replicate the primary's oplog. So when a given
secondary node is ready to update itself, it does three things. First, it looks at the time-
stamp of the latest entry in its own oplog. Next, it queries the primary's oplog for all
entries greater than that timestamp. Finally, it adds each of those entries to its own
oplog and applies the entries to itself. 5 This means that, in case of failover, any second-
ary promoted to primary will have an oplog that the other secondaries can replicate
from. This feature essentially enables replica set recovery.
Secondary nodes use long polling to immediately apply new entries from the pri-
mary's oplog. Thus secondaries will usually be almost completely up to date. When
they do fall behind, because of network partitions or maintenance on secondaries
themselves, the latest timestamp in each secondary's oplog can be used to monitor
any replication lag.

H ALTED REPLICATION
Replication will halt permanently if a secondary can't find the point it's synced to in
the primary's oplog. When that happens, you'll see an exception in the secondary's
log that looks like this:

5

When journaling is enabled, documents are written to the core data files and to the oplog simultaneously in
an atomic transaction.