Databases Reference
In-Depth Information
How It Works
At a very high level, a replicated MongoDB setup always consists of at least two servers,
or nodes. One node is the master and is responsible for handling normal client requests.
The other node(s) is a slave and is responsible for mirroring the data stored on the
master. The master keeps a record of all operations that have been performed on it.
The slave periodically polls the master for any new operations and then performs them
on its copy of the data. By performing all of the same operations that have been per-
formed on the master node, the slave keeps its copy of the data up-to-date with the
master's.
The Oplog
The record of operations kept by the master is called the
oplog
, short for operation log.
The oplog is stored in a special database called
local
, in the
oplog.$main
collection.
Each document in the oplog represents a single operation performed on the master
server. The documents contain several keys, including the following:
ts
Timestamp
for the operation. The
timestamp
type is an internal type used to track
when operations are performed. It is composed of a 4-byte timestamp and a 4-byte
incrementing counter.
op
Type of operation performed as a 1-byte code (e.g., “i” for an insert).
ns
Namespace (collection name) where the operation was performed.
o
Document further specifying the operation to perform. For an insert, this would
be the document to insert.
One important note about the oplog is that it stores only operations that change the
state of the database. A query, for example, would not be stored in the oplog. This
makes sense because the oplog is intended only as a mechanism for keeping the data
on slaves in sync with the master.
The operations stored in the oplog are also not exactly those that were performed on
the master server itself. The operations are transformed before being stored such that
they are idempotent. This means that operations can be applied multiple times on a
slave with no ill effects, so long as the operations are applied in the correct order (e.g.,
an incrementing update, using
"$inc"
, will be transformed to a
"$set"
operation).
A final important note about the oplog is that it is stored in a capped collection (see
“Capped Collections” on page 97
). As new operations are stored in the oplog, they will
automatically replace the oldest operations. This guarantees that the oplog does not
grow beyond a preset bound. That bound is configurable using the
--oplogSize
option
