Database Reference
In-Depth Information
snapshots, which you can use for backups. The problem with
EBS
volumes is that they
don't provide a high level of throughput, especially when compared to what's possible
with physical disks. For this reason, most MongoDB users hosting serious applications
on
EC2
run
EBS
with a
RAID
10 for increased read throughput. This is all but required
for high-performance applications.
For these reasons, rather than dealing with some of
EC2
's limitations and unpre-
dictability, many users prefer to run MongoDB on their own physical hardware. Then
again,
EC2
and the cloud in general are convenient and perfectly acceptable for a
wide variety of users. The lesson is to consider your application and test it in the cloud
before committing to cloud-based storage.
10.1.2
Server configuration
Once you've settled on a deployment environment, you need to decide on an overall
server configuration. This involves choosing a server topology and deciding whether,
and how, to use journaling.
C
HOOSING
A
TOPOLOGY
The minimum recommended deployment topology is a three-member replica set. At
least two members of the set must be data-storing (non-arbiter) replicas residing on
separate machines. The third member may be yet another replica or it can be an arbi-
ter, which doesn't necessarily need its own machine; you can run an arbiter on an
application server, for instance. Two reasonable replica set deployment configurations
are presented in chapter 8.
If you expect your working set size to exceed
RAM
from the start, then you may
want to begin with a sharded cluster, which consists of at least two replica sets.
Detailed recommendation on sharded deployments, along with advice on when to
start sharding, are presented in chapter 9.
You can deploy a single server to support testing and staging environments. But for
production deployments, a single server isn't recommended, even if journaling is
enabled. Having just one machine complicates backup and recovery, and when there's
a server failure, there's nothing to fail over to.
But you can make an exception in certain rare cases. If an application doesn't
need high availability or quick recovery, and has a relatively small data set (say, <
1
GB
), then running on a single server may be permissible. Still, considering the ever-
decreasing costs of hardware, and the numerous benefits of running with replication,
the arguments for foregoing a second machine are weak indeed.
J
OURNALING
MongoDB v1.8 introduced journaling, and MongoDB v2.0 enables journaling by
default. When journaling is enabled, MongoDB will commit all writes to a journal
before writing to the core data files. This allows the MongoDB server to come back
online quickly and cleanly in the event of an unclean shutdown.
Prior to v1.8, no such feature existed, and thus unclean shutdowns often led to
disaster. How was this possible? I've mentioned several times that MongoDB maps
