Database Reference
In-Depth Information
8.1
Replication overview
Replication is the distribution and maintenance of a live database server across multi-
ple machines. MongoDB provides two flavors of replication:
master-slave replication
and
replica sets
. For both, a single primary node receives all writes, and then all secondary
nodes read and apply those writes to themselves asynchronously.
Master-slave replication and replica sets use the same replication mechanism, but
replica sets additionally ensure automated failover: if the primary node goes offline
for any reason, then one of the secondary nodes will automatically be promoted to
primary, if possible. Replica sets provide other enhancements too, such as easier
recovery and more sophistical deployment topologies. For these reasons, there are
now few compelling reasons to use simple master-slave replication.
1
Replica sets are
thus the recommend replication strategy for production deployments; consequently,
I'll devote the bulk of this chapter to explanations and examples of replica sets, with
only a brief overview of master-slave replication.
8.1.1
Why replication matters
All databases are vulnerable to failures of the environments in which they run. Repli-
cation provides a kind of insurance against these failures. What sort of failure am I
talking about? Here are some of the more common scenarios:
The network connection between the application and the database is lost.
Planned downtime prevents the server from coming back online as expected.
Any institution housing servers will be forced to schedule occasional downtime,
and the results of this downtime aren't always easy to predict. A simple reboot
will keep a database server offline for at least a few minutes. But then there's the
question of what happens when the reboot is complete. There are times when
newly installed software or hardware will prevent the operating system from
starting up properly.
There's a loss of power. Although most modern data centers feature redundant
power supplies, nothing prevents user error within the data center itself or an
extended brownout or blackout from shutting down your database server.
A hard drive fails on the database server. Frequently having a mean time to fail-
ure of just a few years, hard drives fail more often than you might think.
2
In addition to protecting against external failures, replication has been important for
MongoDB in particular for durability. When running without journaling enabled,
MongoDB's data files aren't guaranteed to be free of corruption in the event of an
unclean shutdown. Without journaling, replication must always be run to guarantee a
clean copy of the data files if a single node shuts down hard.
1
The only time you should opt for MongoDB's master-slave replication is when you'd require more than 11
slave nodes, since a replica set can have no more than 12 members.
2
You can read a detailed analysis of consumer hard drive failure rates in Google's “Failure Trends in a Large
Disk Drive Population” (
http://research.google.com/archive/disk_failures.pdf
)
.
