In the previous chapters, you learned the basic terms and fundamentals needed to work with a replica set network in MongoDB. Now, it's time to examine a replica set in action through a practical example.
In this chapter, we will set up a new replica set from scratch to provide a readily available MongoDB server. Furthermore, we will see the failover process of replica sets in action. You will learn all the steps using screenshots, so it will be easier to follow the procedure.
There are two ways to deploy a replica set, for production or development, and testing. In this chapter, we will deploy replica set for production use. The same procedure is used to deploy a replica set in a development environment, but the requirements are different.
A three-member replica set can provide enough power to overcome network and server issues. To have a smooth election process, it's recommended that you have an odd number of members in a replica set.
The following diagram shows a replica set with three members:
Likewise, for production use of a replica set, each replica set should be hosted on different machines. As you are aware, each machine can face network or hardware failure, so by hosting Missing object type instance on different machines, we can make sure that if a machine fails, we won't lose all the mongod processes.
There are some steps you need to take before starting a replica set deployment. First of all, you should make sure that you have the latest stable version of MongoDB on each machine.
If you haven't installed MongoDB yet and need help installing MongoDB, read these short instructions at http://docs.mongodb.org/manual/installation/.
Additionally, before deploying a replica set, you must make sure that there aren't any network issues between replica set members. Each machine must see the other, and you must configure the firewall not to prevent connections. In order to have an effective replica set, you should configure the machine so that every member can connect to the other.
If you want a procedure to check the connection between members, visit http://docs.mongodb.org/manual/tutorial/troubleshoot-replica-sets/#replica-set-troubleshooting-check-connection.
In our example, we will create a replica set using three members on different machines. The following is the configuration of each machine:
Mac OS X 10.9.2
Ubuntu 12.04
Ubuntu 12.04
We have Mac OS X on our host machine, and we use VMware Fusion to run other machines at once. The network connections between members are provided by VMware Fusion. Each mongod object will be hosted on different machines, so we will have three members on three separate machines.
The following scheme shows each machine's hostname:
mongod1.replicaset.com
mongod2.replicaset.com
mongod3.replicaset.com
You can set up hostnames by configuring DNS settings or adding hostnames to the hosts file. This file can be found in the /etc/ folder of the Unix operating systems.
The following diagram shows the member's network and relationships:
It's obvious that according to the situation, secondaries can become primaries. For instance, if mongod2.replicaset.com receives the majority of the votes, it...
Having completed the initialization steps, we can now start to define our first replica set. First of all, you need to run the mongod process on all machines through the following steps:
Make sure that you have the configuration file in your machine, and then run the following command:
mongod --config /etc/mongodb.conf
After issuing the command, you should see the result depicted in the following screenshot:
Because we set the fork property to true, mongod will run as a daemon in the background. So, in order to see the logs and outputs of mongod, you should use the defined logpath file. You can see the logfile content as shown in the following screenshot:
For the next steps, you should use mongo interactive shell to run and configure the replica set.
Run the mongo command from your...
In this section, we will deactivate the specific nodes to force the replica set to make an election and change the nodes' role.
First of all, we will deactivate one of the secondary nodes by stopping the mongod service on the secondary machine.
Right after stopping the service of mongod3.replicaset.com, the replica set will set this node as an unreachable secondary node, as shown in the following screenshot:
The status of the replica set shows that the third member has an issue, so this member becomes unavailable until the replica set gets a ping from it. After starting the service again, the members' status changes again as shown in the following screenshot:
Network issues or hardware failure on the member's machine also has the same result as stopping the MongoDB service.
For the next test, we will halt the primary node's service. After stopping the service in the primary node, the replica set uses an election process to choose the next primary node from secondary nodes...
In this chapter, we studied how to create a replica set from scratch to provide a readily available MongoDB server. First of all, we discussed the basic considerations of a replica set. Next, we configured the workspace to run the replica set. Additionally, we learned basic replica set commands in order to add or remove members from the replica set.
In our example, we had a three-member replica set, one primary and two secondary nodes. After configuration and setup, to test the replica set, we deactivated different nodes in the replica set. Also, we found that upon disabling the primary node, the replica set will choose another primary node from the active secondary members using an election process.
Also, we learned to run an arbiter node and add it to an existing replica set network. We found that arbiter nodes won't save and hold data at all.
In the next chapter, we will learn sharding in MongoDB, and distributing a dataset into different servers and machines.
© 2014 Packt Publishing Limited All Rights Reserved
