You should enable JavaScript to get a nice table of content for this page.

Why a MongoDB Replica Set?

MongoDB is a document storage server. It is very
comfortable to work with it because of the flexibility in which one
can store, retrieve and update documents in the database while keeping
relatively good performances. As with any system, one needs to be
aware of the limitations to correctly use it.

A very nice thing of MongoDB is the support of replica sets. A
replica set is a basically a couple of servers put together to
replicate and serve the data. Simple replication was at the core of
the design decisions of MongoDB and as such, it makes the setup
really easy.

The logic behind replicat set is to always have at least 3 warm copies
of the data at anytime. It does not exempt you from doing backups, but
it allows you to have continuity of service in case of a one replica
failure. This is good when you want to sleep at night.

I like to create automated scripts to rebuild automatically the
services after a failure, you should do the same. As I like Python, I
am using fabric.

The setup is done with MongoDB 1.8.3 but is the same with
2.0.1. You can read the upgrade procedure from 1.8 to 2.0 near the
end of this note.

Debian Squeeze Setup

The base Debian Squeeze is extremely easy to setup, you can
refer to the Ganeti notes to have an idea of how the
setup is done, what is important is that:

each VM has a public IP address and can access the Internet to
easily download software, perform updates;

each VM has a private IP address to communicate with the other
MongoDB VMs and with the administration backend.

To save IPv4 in the future, non critical VMs should get only a private
IP and use a proxy to access the outside world.

MongoDB Setup

The setup is performed directly from the tarball. It may be seen as
strange to use the tarball when Debian and Ubuntu packages
are available, put I prefer to be able to run on the version I want
and upgrade by simply downloading and copying the new binaries at the
right place.

The setup is simple:

create the mongodb user under which MongoDB will run;

create the directories to store the data and the logs;

copy the configuration and the init script at the right place;

install the init script.

It is maybe one of the simplest database server to install, with a
Fabric recipe, it takes me about 5 seconds per host to have
MongoDB installed and configured including the download time.

As I extract the MongoDB archive in /home/mongodb, I need to symlink
the mongod binary to have it in the path at the right place:

ln -s /home/mongodb/bin/mongod /usr/bin/mongod

Copy the Configuration and Init Script

As you noticed when creating the log and data path, by default Debian
does not follow the same conventions as MongoDB, that is, the
databases are stored in /var/lib/mongodb and not /data/db. From a
sysadmin point of view, it is easier to follow the Debian way for
everything, so here is my base configuration, please note the
bind_ip to have MongoDB open only on the private network:

Yes, the configuration is simple, data durability is maintained
using a replica set with 3 nodes and without journaling.

The MongoDB init script is simply copied as /etc/init.d/mongodb and
installed using the new dependency based boot system. I am
using a small variation of the one provided by default. The difference is that I let MongoDB control the
PID file. You can get the file at the end of this document.

# insserv mongodb

You can now start MongoDB on each server and go to the next step, get
the configuration of the replica set.

Replica Set Configuration

First, you need to be sure that your VMs can in a way or another
resolve the IP addresses of all the servers involved in your replica
set. You can either do that with a DNS entry or less flexible in your
/etc/hosts file. This is up to you.

Enjoy, your replica set is now running. It is time for you to dive
into all the documentation regarding backup and monitoring on the
MongoDB website.

Security Considerations

By default, MongoDB binds on all the interfaces, do not forget to
restrict to an IP of your private network.

Upgrading

When note specified, the database storage is compatible from version n to n + 0.2, so the upgrade is mostly painless.

Make a backup of your database;

Download and extract the new version;

Change the symlink to point to the new mongod;

Restart all the mongod one by one. This will fail the master over a secondary and keep your replica set up.

Rotation of the Log Files

You want
rotation
of your log files to avoid saturation of your /var partition. These
settings are rotating every week the logs. Because copytruncate is
used, you may lose some information, but this is not really a problem
as normally, a MongoDB cluster is monitored by connecting to the
server itself and running stats queries.