IntroductionIn 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.
Table of ContentsPart 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
ServersWe 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?
NextIn the next section, we will install MongoDB on our servers and configure Replica Sets. Click here to proceed.
Share the joy:
Subscribe by reader Subscribe by email Share