Database Reference
In-Depth Information
Of course, replication is desirable even when running
with
journaling. After all,
you still want high availability and fast failover. In this case, journaling expedites recov-
ery because it allows you to bring failed nodes back online simply by replaying the
journal. This is much faster than resyncing from an existing replica or copying a rep-
lica's data files manually.
Journaled or not, MongoDB's replication greatly increases the reliability of the
overall database deployments and is highly recommended.
8.1.2
Replication use cases
You may be surprised at how versatile a replicated database can be. In particular, repli-
cation facilitates redundancy, failover, maintenance, and load balancing. Here we take
a brief look at each of these use cases.
Replication is designed primarily for redundancy. It essentially ensures that repli-
cated nodes stay in sync with the primary node. These replicas can live in the same
data center as the primary, or they can be distributed geographically as an additional
failsafe. Because replication is asynchronous, any sort of network latency or partition
between nodes will have no affect on the performance of the primary. As another
form of redundancy, replicated nodes can also be delayed by a constant number of
seconds behind the primary. This provides insurance against the case where a user
inadvertently drops a collection or an application somehow corrupts the database.
Normally, these operations will be replicated immediately; a delayed replica gives
administrators time to react and possibly save their data.
It's important to note that although they're redundant, replicas aren't a replace-
ment for backups. A backup represents a snapshot of the database at a particular time
in the past, whereas a replica is always up to date. There are cases where a data set is
large enough to render backups impractical, but as a general rule, backups are pru-
dent and recommended even when running with replication.
Another use case for replication is failover. You want your systems to be highly
available, but this is possible only with redundant nodes and the ability to switch over
to those nodes in an emergency. Conveniently, MongoDB's replica sets can frequently
make this switch automatically.
In addition to providing redundancy and failover, replication simplifies mainte-
nance, usually by allowing you to run expensive operations on a node other than the
primary. For example, it's common practice to run backups against a secondary node
to keep unnecessary load off the primary and to avoid downtime. Another example
involves building large indexes. Because index builds are expensive, you may opt to
build on a secondary node first, swap the secondary with the existing primary, and
then build again on the new secondary.
Finally, replication allows you to balance reads across replicas. For applications
whose workloads are overwhelmingly read-heavy, this is the easiest way to scale
MongoDB. But for all its promise, scaling reads with secondaries isn't practical if any
of the following apply:
