How to deploy a MongoDB cluster (version 3.4)

I worked on a project theses days on a project based on MongoDB. The project was to allow a customer to have have his account history (all transactions he have made) on nearly real time in telco environment. Due to some reasons we have choose to use MongoDB technology and due to the fact that we are talking about terabytes of data a MongoDB Cluster was needed. After digging on internet I successed to do it. ( by the way, the project was a success)

This article will show to you steps I followed to configure my cluster on MongoDB 3.4 during the project. We wanted to have a cluster of three Replica Sets and two routers. For optimization purpose we choosed to have 3 nodes per Replica Set (one primary, one secondary and one arbiter) and to launch all arbiters on the same node due to the fact they are not resources consuming.

Let’s start configurations.

Preparation

We assume that you are working on linux and MongoDB is well installed. If not, consult this link: https://docs.mongodb.com/manual/administration/install-on-linux/

If MongoDB is installed, all nodes need to be configured depending of thier purpose (Replica set, config servers or routers).

# Configure data directory
mkdir /data/mongo-metadata
chown -R mongod:mongod /data/mongo-metadata/

Configuration of node:

# Configure data directory
dbPath = /data/mongo-metadata/
bindIp = 0.0.0.0
replication:
  replSetName: replica-name or config-name
sharding:
  clusterRole: shardsvr or configsvr

Explanation:

• replSetName and clusterRole change depending of the node
• replSetName will be rs1, rs2 or rs3 for replica set and cs for config servers.
• clusterRole will be shardsvr for replica set configsvr for config servers.

Now that everything is configured, let’s start the configuration of the MongoDB Cluster.

Config Servers

Config Servers contains all metadata of your MongoDB Cluster. All the mapping of your data in your MongoDB Cluster are stored here. If they fall, all your MongoDB Cluster is down. In this version of MongoDB (since the version 3) config servers are configured as a replicat set and in our case here we will named it cs. As recommended by MongoDB, we will use three nodes with the following host name: host-conf01, host-conf02 and host-conf03.

To configure it, make connection on a mongo shell on one the nodes and type commands below:

rs.initiate(
  {
    _id: "cs",
    configsvr: true,
    members: [
      { _id : 0, host : "host-conf01:27017" },
      { _id : 1, host : "host-conf02:27017" },
      { _id : 2, host : "host-conf03:27017" }
    ]
  }
)

Replica Set configuration

Replica Set is a set of mongo db nodes which maintain the same data set. It provide a high data availability and redundancy in production environment. In Replica Set you have an primary node which handle write and read operations and secondary node which handle read operations. When the primary node failed, one of the secondary nodes become the primary node.

In some case you can setup a arbiter, his purpose is to handle the election between the secondary nodes in case of the unavailability of the primary node. He doesn’t have any data of the Replica Set: it is simply used for the election. In our case, we will have two nodes and on aribiter: one primary, one secondary and on arbiter.

Replica Set configuration

For each Replica Set connect on the mongo shell of each primary node and type the command below:

rs.initiate( {
   _id : "rs1",
   members: [ { _id : 0, host : "host-replica-rs1-1:27017" } ]
})
rs.add("host-replica-rs1-2:27017")
rs.addArb("host-arbiter:30000")
rs.status()

Explanation:

• You need to repeat the process above on the primary node of each Replica Set.
• rs1 is the name of the Replica Set you can change it
• host-replica-rs1-1 is the hostname of the primary node
• host-replica-rs1-2 is the hostname of the secondary node
• host-arbiter is the hostname of the arbiter

NB: In our architecture all arbiters are launched on the same node so you need to change the port when you configure your Replica Set. For example here (on rs1 the port is 30000, on rs2 it ca be 30001, …)

Forcing the priority

In some case you want that to give priority on some node in case of election. So if this node is available during and election of the primary node, it will be privileged.

To do so, just connect on the mongo shell of the primary node and type the command below.

cfg = rs.conf();
cfg.members[0].priority = 10;
cfg.members[1].priority = 5;
# ...
rs.reconfig(cfg);
rs.conf();

MongoDB Cluster configuration

Replica Set and Configs Server are now OK. Let’s put the final piece of our puzzle: let’s put all those elements together.

In order to do that, you need to start the mongos client, connect to the mongos client and add Replica Set to your MongoDB Cluster.

Start the mongos client (launch the router)

First of all make sure that mongod service is not started on the server if it is the case stop it then type the command below:

sudo -u mongod mongos --logpath /var/log/mongodb/mongos.log  --configdb cs/host-conf01:27017,host-conf02:27017,host-conf03:27017 &

If you recall a MongoDB Cluster have 3 part: Config Servers, Replica Set and Router. We was good with Replica Set and Config Servers  and now we are good with routers because to define a router, you just need to launch a mongos instance.

Add Replica Set to the MongoDB Cluster

Connect to his mongo client once the mongos is launched and type the commands below:

sh.addShard( "rs1/host-replica-rs1-1:27017")
sh.addShard( "rs1/host-replica-rs1-2:27017") 
sh.addShard( "rs2/host-replica-rs2-1:27017") 
sh.addShard( "rs2/host-replica-rs2-2:27017") 
sh.addShard( "rs3/host-replica-rs3-1:27017") 
sh.addShard( "rs3/host-replica-rs3-2:27017")

Conclusion

These are the steps that I used to configure my MongoDB Cluster. Today our MongoDB Cluster have 3 Replica Set (with two nodes and on arbiter) and everything is working good.
Thanks you very much for reading this article.

Sources:

• https://docs.mongodb.com/