Databases Reference
In-Depth Information
when starting the server, which allows you to specify the size of the oplog in megabytes.
By default, 64-bit instances will use 5 percent of available free space for the oplog. This
space will be allocated in the
local
database and will be preallocated when the server
starts.
Syncing
When a slave first starts up, it will do a full sync of the data on the master node. The
slave will copy every document from the master node, which is obviously an expensive
operation. After the initial sync is complete, the slave will begin querying the master's
oplog and applying operations in order to stay up-to-date.
If the application of operations on the slave gets too far behind the actual operations
being performed on the master, the slave will fall
out of sync
. An out-of-sync slave is
unable to continue to apply operations to catch up to the master, because every oper-
ation in the master's oplog is too “new.” This could happen if the slave has had down-
time or is busy handling reads. It can also happen following a full sync, if the sync takes
long enough that the oplog has rolled over by the time it is finished.
When a slave gets out of sync, replication will halt, and the slave will need to be fully
resynced from the master. This resync can be performed manually by running the
command
{"resync" : 1}
on the slave's
admin
database or automatically by starting
the slave with the
--autoresync
option. Either way, doing a resync is a very expensive
operation, and it's a situation that is best avoided by choosing a large enough oplog size.
To avoid out of sync slaves, it's important to have a large oplog so that the master can
store a long history of operations. A larger oplog will obviously use up more disk space,
but in general this is a good trade-off to make (hence the default oplog size of 5 percent
of free space). For more information on sizing the oplog, see
“Administra-
tion” on page 141
.
Replication State and the Local Database
The
local database
is used for all internal replication state, on both the master and the
slave. The local database's name is
local
, and its contents will never be replicated.
Thus, the local database is guaranteed to be local to a single MongoDB server.
Use of the local database isn't limited to MongoDB internals. If you have
documents that you don't want to replicate, just store them in a collec-
tion in the local database.
