Introduction

In this tutorial, we will study how to setup MongoDB Replica Sets using a Spring Data MongoDB-based application for testing our replica sets. We will not create a MongoDB application here but instead we will reuse an existing one from the Spring MVC 3.1 - Implement CRUD with Spring Data MongoDB guide. For this study, we will use production-ready, cloud servers to demonstrate in real-time the results.

Part 1: Introduction
Part 2: Installation and configuration of Replica Sets
Part 3: Spring app configuration
Part 4: Testing the servers

What is a Replica Set?

Replica sets are a form of asynchronous master/slave replication, adding automatic failover and automatic recovery of member nodes.

A replica set consists of two or more nodes that are copies of each other. (i.e.: replicas)

The replica set automatically elects a primary (master). No one member is intrinsically primary; that is, this is a share-nothing design.

Drivers (and mongos) can automatically detect when a replica set primary changes and will begin sending writes to the new primary.

Replica sets have several common uses:

Data Redundancy

Automated Failover / High Availability

Distributing read load

Simplify maintenance (compared to "normal" master-slave)

Disaster recovery

Source: MongoDB Replica Sets

Servers

We have four cloud servers (for security purposes, I have modified their actual IP addresses). All servers are running with the following configuration:

OS: CentOS release 5.2 (Final)
RAM: 512MB
HD: 30GB

Here are our servers:

Server #	IP address	MongoDB port	Comments
Server 1	123.456.78.90	27017	primary server
Server 2	123.456.78.91	27017	slave server
Server 3	123.456.78.92	27017	slave server
Server 4	123.456.78.93	27017	arbiter server (see note below)

Although Server 1 is the primary server, this is not permanent. Whenever the primary server is down, another server is elected as a primary. Server 4 is an arbiter server which is useful for certain cases in electing a primary server.

Note: Our Spring Data MongoDB-based application is hosted in Server 1.

What is an Arbiter?
Arbiters are nodes in a replica set that only participate in elections: they don't have a copy of the data and will never become the primary node (or even a readable secondary). They are mainly useful for breaking ties during elections (e.g. if a set only has two members).

When to add an arbiter

Two members with data : add an arbiter to have three voters. 2 out of 3 votes for a member establishes it as primary.

Three members with data : no need to add an arbiter. In fact having 4 voters is worse as 3 of 4 needed to elect a primary instead of 2 of 3. In theory one might add two arbiters thus making number of votes five, and 3 of 5 would be ok; however this is uncommon and generally not recommended.

Four members with data : add one arbiter.

Source: MongoDB - Adding an Arbiter

Do I need an Arbiter?
You need an arbiter if you have an even number of votes. As an extension to this, at most you should only ever have 1 arbiter. If you aren't sure how many votes you have, it's probably the same as the number of servers in the set you have (including slaves, hidden, arbiters).

Source: Does My MongoDB Replica Set Need An Arbiter?