Java Login

About javalogin.com

Hello guys,
javalogin.com is for Java and J2EE developers, all examples are simple and easy to understand 

It is developed and maintained by Vaibhav Sharma. The views expressed on this website are his own and do not necessarily reflect the views of his former, current or future employers. I am professional Web development. I work for an IT company as Senior Consultant. Primary I write about spring, hibernate and web-services. I am trying to present here new technologies.


     << Previous
Next >>     


MongoDB Replication


A replica set in MongoDB is a group of mongod processes that maintain the same data set. The database replication offers various benefits depending on its type and the options you choose, but the common benefit of replication is the availability of data when and where it is needed. As a result, you will experience improved availability of replicated data. If data from one database server is unavailable, customers can still access the replicated copy of the data.

A replica-set consists of one Master (also called "Primary") and one or more Slaves (aka Secondary). Read-operations can be served by any slave, so you can increase read-performance by adding more slaves to the replica-set (provided that your client application is capable to actually use different set-members). But write-operations always take place on the master of the replica-set and are then propagated to the slaves, so writes won't get faster when you add more slaves.

Replica-sets also offer fault-tolerance. When one of the members of the replica-set goes down, the others take over. When the master goes down, the slaves will elect a new master. For that reason it is suggested for productive deployment to always use MongoDB as a replica-set of at least three servers, two of them holding data (the third one is a data-less "arbiter" which is required for determining a new master when one of the slaves goes down).




Master-slave replication is the most general replication mode supported by MongoDB. This mode is very flexible and can be used for backup, fail-over, read scaling, and more




Why Replication?

There are some point provide by replica set.

  • Many users can work with their own local copy of a database.
  • In replication, you have more copy for reporting, recovery and backup
  • Keep data safe on different node
  • Read scaling
  • No down time for maintenance
  • High availability of data on different node

Configuration Replica Set

Let's follow the given steps to create and configure the 3 nodes replica sets in MongoDB on local machine. The configuration should be as mentioned below:
Port 27017 (default port) - primary node, 1.log as log file name 1.log, data file in rs1
Port 27018 - secondary node, 2.log as log file name, data file in rs2
Port 27019 - secondary node, 3.log as log file name, data file in rs3.
The replica sets name is "davi".

Step 1:
you need to create three directories to store three mongod instances data separately.
Open command prompt and give the following command.
C:\> mkdir \data\rs1 \data\rs2 \data\rs3




Step 2:
Now let's start three mongod instances as follows.
mongod.exe --replSet davi --logpath \data\rs1\1.log --dbpath \data\rs1 --port 27017 --smallfiles --oplogSize 64




mongod.exe --replSet davi --logpath \data\rs2\2.log --dbpath \data\rs2 --port 27018 --smallfiles --oplogSize 64




mongod.exe --replSet davi --logpath \data\rs3\3.log --dbpath \data\rs3 --port 27019 --smallfiles --oplogSize 64




Now three mongod servers are running but they are not configured or initialized yet to interconnect to work for replica sets.
Step 3 You need to interconnect all three nodes. You need to open a command prompt and write configuration code and finally you need to call rs.initiate(config) command to start the replica sets as expected. I am giving replica sets names as "davi" but you can give it any other name.
Open new command prompt and give the following command.
C:\> mongo --port 27017


> config = {_id:"davi",members: [
{_id: 1, host: "localhost:27017"},
{_id: 2, host: "localhost:27018"},
{_id: 3, host: "localhost:27019"}]
};

> rs.initiate(config);






Now replica sets with three nodes is setup and configured successfully. You can check the status of the replica sets with rs.status().
davi:PRIMARY> rs.status();





if you observe the above result set its clearly written that there are three nodes and localhost:27017 is the primary and rest two are secondary nodes.
Congratulations!!! The replication system named as "davi" is now ready to use.

Testing
Now we need to insert a document into the primary node and after insertion read the inserted document.

davi:PRIMARY> db.assignment.insert({name:"Up", duedate: "19th January"});

davi:PRIMARY> db.assignment.find();





Now let's connect with a secondary node and read the data inserted by the primary node. If we read the data in the secondary node means the secondary nodes are in sync with the primary node and primary node's replication is available to all secondary nodes.

To connect with the localhost:27018 by opening another command prompt and connect with a secondary node localhost:27018. After connecting with localhost:27018 and once you try to read the data from the node, it gives you an error because by default you cannot read from the secondary node. To read data from the secondary node you need to give the command rs.slaveOk().

The reason for issuing rs.slaveOk() or db.getMongo().setSlaveOk() command while querying on secondaries. We've to set "slave okay" mode to let the mongo shell know that we're allowing reads from a secondary. This is to protect our applications from performing eventually consistent reads by accident. C:\> mongo --port 27018

davi:SECONDARY> db.assignment.find();

davi:SECONDARY> rs.slaveOK();

davi:SECONDARY> db.assignment.find();





you can only read data from the secondary nodes but cannot insert document to the secondary nodes. Try the following query which gives you error.
davi:SECONDARY> db.assignment.insert({name:"The day after tomorrow", duedate: "19th January"});





Replication Internals

To know how this replication is happening iternally, you need to analyze the oplog.rs file in each nodes including primary and secondary.
Let's connect to the primary node (localhost:27017) and switch to local database. You can use show collections command to see all the collections present in the local database.
Finally, you can see the oplog.rs file by giving the query db.oplog.rs.find().pretty()

C:\> mongo --port 27017

davi:PRIMARY> use local
davi:PRIMARY> show collections
davi:PRIMARY> db.oplog.rs.find().pretty();





Failover in Replication

To see the failover situation in replica sets, let's shutdown the primary node. It can be clearly seen in which node you are now in the command prompt. But if you want to check from command, you can give rs.isMaster(). If you are in the secondary node, you need to connect to the localhost:27017 i.e. primary node. Once you are inside the primary node, we need to shutdown the primary node giving the db.shutdownServer() command. Once the primary server is down there will be automatic election process to select the a new primary node which will take only a few milliseconds.


C:\> mongo --port 27017
davi:PRIMARY> db.shutdownServer();
davi:PRIMARY> use admin
davi:PRIMARY> db.shutdownServer();





Now let's connect to localhost:27018 and give the rs.status() command. In the result set it can be seen that one of the two secondary nodes becomes primary. Whenever the previously shutdown node becomes up, it will be secondary.


C:\> mongo --port 27018
davi:PRIMARY> rs.status();



To see what happens when the previous node is down but one document is inserted into the newly elected primary node. Its very simple, whenever the previously down server becomes up it becomes as secondary node and sync all the data (oplog.rs) that is in the new elected primary nodes. Let's see this scenario in the following section.

  1. Inserting a assignment document into the new primary node.
  2. davi:PRIMARY> db.assignments.insert({name: "The Day After Tomorrow", duedate: 2004});
  3. Make the previously down node to up open new cmd and put code of step 5
  4. mongod.exe --replSet davi --logpath \data\rs1\1.log --dbpath \data\rs1 --port 27017 --smallfiles --oplogSize 64
  5. Connect to the localhost:27017 (which was down before) and you can see all the documents including the inserted documents when it was down.
  6. Lastly, you can check the oplog.rs file and if you match it primary ndoe. Its similar as primary node.



C:\> mongo --port 27017
davi:SECONDARY> rs.slaveOk();
davi:SECONDARY> db.assignments.find();

davi:SECONDARY> usetest
davi:SECONDARY> show collections
davi:SECONDARY> db.oplog.rs.find().pretty();


Great! Your MongoDB cluster has been configured! Now you can rest assured in the security of your data.


     << Previous
Next >>