The MongoDB database was written in C++. It is among the leading NoSQL databases today. One can achieve a lot in terms of a database with MongoDB. The database offers automatic scaling, high performance, and high availability to database developers.
Chapter 2- Deploying a Replica Set
We need to discuss the process by which one can create a three-member replica set from three MongoDB existing instances which are executed with access control already disabled.
When you have three member replica sets, you will ensure that there is enough redundancy for enabling us to survive failures such as network partitions. They will also provide us with enough capacity to cater to the distributed read operations. The number of members in the replica sets should always be an odd number. This ensures that the elections are done smoothly.
You just have to start the MongoDB instances that are to become members of the replica set, perform a configuration of the replica set, and then have the instances of the MongoDB added to it.
For production deployments, the instances of MongoDB have to be stored in different machines so as to ensure that there is much separation between the members. For those using virtual machines for production deployments, each instance of the MongoDB has to be placed in different host servers serviced by redundant network paths and redundant power circuits.
The procedure
The following steps are necessary for deployment of a replica set when the access control has been disabled:
- Use the appropriate options to start each member of your replica set
A mongod should be started for each member and the name of the replica set specified through the option for replSet. For applications connecting to more than one replica set, a distinct name should be specified for each set.
Let us use the option replSet to specify the name of our replica set:
mongod --replSet "rs0"
The specification for this can also be done in the configuration file. For the mongod to be started together with the configuration file, we can use the config option so as to specify this:
mongod --config $HOME/.mongodb/config
In production deployments, an init script can be configured for management of this process.
- Connection of the mongo shell to the replica set member
Assuming that you have your mongod running on localhost and on the port 27017, which is the default one, you can use the following:
Mongo
- Initiation of the replica set
One should use the function rs.initiate() on their replica set member. This is shown below:
rs.initiate()
MongoDB will initiate a set having the current member, and it will use the default configuration for the replica set.
- Verifying the initial configuration of the replica set
The displaying of the replica set configuration object can be done by use of the method rs.conf() . The configuration object for the replica set is as follows:
{
"_id" : "rs0",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "mongodb0.example.net:27017"
}
]
}
- The remaining members should then be added to the replica set.
This can be done by use of the method rs.add() . Consider the following example, which shows how two members can be added:
rs.add("mongodb0.example.net")
rs.add("mongodb1.example.net")
After completion, you will have a fully functional replica set. It will then elect the primary.
- The status of the replica set can then be checked.
The following method can be used to perform this operation:
rs.status()
Chapter 3- Adding members to a Replica Set
An additional member can be added to a replica set which is already in existence. Note that each replica set should have a maximum of seven voting members. For one to add a new member to a replica set which has seven members, you have to add the new member as a non-voting member or remove a vote from one of the existing members.
In the case of production deployments, an init script can be configured for the purpose of management of the member processes.
A member who has been removed from the replica set can be re-added. If the removal of the member had been done recently, the member can be recovered and catch up easily.
For those having a snapshot or a backup of an existing member, the data files can be moved to a new system and then quickly used for initiation of a new member. The files have to be:
- A copy of data files which are valid for a member belonging to the same replica set.
- The most recent operation in the primarys oplog. The new member has to become the current one once the operations from the primarys oplog have been applied.
Requirements
You should have the following:
- A replica set which is active.
- A new MongoDB system with the ability to support your data set, and be accessible by your active replica set throughout your network.
The Procedure
- Preparation of the Directory
Before we can add the new member to the replica set, we have to prepare the data directory for the new members. You can use any one of the following strategies:
- Make sure that the data directory for new members has no data. Data will be copied from an existing member by the new member. For a new member in a recovering state, it has to exit and then become a secondary before all the data can be copied by MongoDB as part of the replication process. Note that some time will be required for this process to take place, but the administrator will not be required to intervene in any way.
- The data directory has to be copied manually from the existing member. The new member will become a secondary member, and it will catch up to the current state of our replica set. When we copy the data, the amount of time required for the new member to become the current one will be shortened.