Databases Reference
In-Depth Information
Read Scaling
One way to scale reads with MongoDB is to issue queries against slave nodes. By issuing
queries on slaves, the workload for the master is reduced. In general, this is a good
approach to scaling when your workload is read heavy—if you have a more write-
intensive workload, see
Chapter 10
to learn how to scale with autosharding.
One important note about using slaves to scale reads in MongoDB is
that replication is asynchronous. This means that when data is inserted
or updated on the master, the data on the slave will be out-of-date mo-
mentarily. This is important to consider if you are serving some requests
using queries to slaves.
Scaling out reads with slaves is easy: just set up master-slave replication like usual, and
make connections directly to the slave servers to handle queries. The only trick is that
there is a special query option to tell a slave server that it is allowed to handle a query.
(By default, queries will not be executed on a slave.) This option is called
slaveOkay
,
and all MongoDB drivers provide a mechanism for setting it. Some drivers also provide
facilities to automate the process of distributing queries to slaves—this varies on a per-
driver basis, however.
Using Slaves for Data Processing
Another interesting technique is to use slaves as a mechanism for offloading intensive
processing or aggregation to avoid degrading performance on the master. To do this,
start a normal slave, but with the addition of the
--master
command-line argument.
Starting with both
--slave
and
--master
may seem like a bit of a paradox. What it
means, however, is that you'll be able to write to the slave, query on it like usual, and
basically treat it like you would a normal MongoDB master node. In addition, the slave
will continue to replicate data from the actual master. This way, you can perform
blocking operations on the slave without ever affecting the performance of the master
node.
When using this technique, you should be sure never to write to any
database on the slave that is being replicated from the master. The slave
will not revert any such writes in order to properly mirror the master.
The slave should also not have any of the databases that are being re-
plicated when it first starts up. If it does, those databases will not ever
be fully synced but will just update with new operations.
