Mongodb Replica Set

                  This guide explains the concepts of configuring a two replica set.It also explains about clearly about Replica Set,Primary members,Secondary members,Arbiter,Secondary member,Priority 0 Members,Hidden Replication Members,Delayed Replication Members.Also how to configure the replica set in a shard. 

Replica Set:

              A replica set in MongoDB is a group of mongod processes that maintain the same data set.Replica sets provide redundancy and high availability, and are the basis for all production deployments.The main difference between the Master-slave replication and the Replica set is that Replica set has automatic failover options.The Master-slave replication has manual failover options.So the Replica set options are more preferred than the Master-slave replication.

Primary members:

             The primary is the only member in the replica set that receives write operations. MongoDB applies write operations on the primary and then records the operations on the primary’s oplog. Secondary members replicate this log and apply the operations to their data sets.

Secondary members:

             Secondary replicate operations from the primary to maintain an identical data set. Secondaries may have additional configurations for special usage profiles. For example, secondaries may be non-voting or priority 0.

Arbiter:

             An arbiter does not have a copy of data set and cannot become a primary. Replica sets may have arbiters to add a vote in elections of for primary. Arbiters allow replica sets to have an uneven number of members, without the overhead of a member that replicates data.

Secondary member Customization:

            There are instances where you may not want all of your secondary members to be beholden to the standard rules for a replication set. A replication set can have up to 12 members and up to 7 will vote in an election situation.

Priority 0 Replication Members:

            There are some situations where the election of certain set members to the primary position could have a negative impact on your application's performance.For instance, if you are replicating data to a remote data center or a specific member's hardware is inadequate to perform as the main access point for the set, setting priority 0 can ensure that this member will not become a primary but can continue copying data.

Hidden Replication Members:

             Some situations require you to separate the main set of members accessible and visible to your clients from the background members that have separate purposes and should not interfere.For instance, you may need a secondary member to be the base for analytics work, which would benefit from an up-to-date dataset but would cause a strain on working members. By setting this member to hidden, it will not interfere with the general operations of the replication set.Hidden members are necessarily set to priority 0 to avoid becoming the primary member, but they do vote in elections.    

Delayed Replication Members:

             By setting the delay option for a secondary member, you can control how long the secondary waits to perform each action it copies from the primary's oplog.This is useful if you would like to safeguard against accidental deletions or recover from destructive operations. For instance, if you delay a secondary by a half-day, it would not immediately perform accidental operations on its own set of data and could be used to revert changes.Delayed members cannot become primary members, but can vote in elections. In the vast majority of situations, they should be hidden to prevent processes from reading data that is out-of-date.

Configuring a replica set:

Let us assume to create a replica set with the following architecture:

Step 1:Create the required data directories. Creating a replica set with the name firstset,Start a mongod instance as follows for primary(10001) as follows:

./mongod --dbpath /data/example/firstset1 --port 10001 --replSet firstset --oplogSize 700 --rest

Step 2:Create a mongod instance as follows for a secondary(10002):

./mongod --dbpath /data/example/firstset2 --port 10002 --replSet firstset --oplogSize 700 --rest

Step 3:Create a mongod instance as follows for another secondary(10003):

./mongod --dbpath /data/example/firstset3 --port 10003 --replSet firstset --oplogSize 700 --rest

Step 4:Open a mongo instance for the primary(10001) as follows:

./mongo localhost:10001/admin

Step 5:Now initiate the primary(10001) replica set to the mongo instance as follows:

db.runCommand({"replSetInitiate" : {"_id" : "firstset", "members" : [{"_id" : 1, "host" : "localhost:10001"}, {"_id" : 2, "host" : "localhost:10002"}, {"_id" : 3, "host" :"localhost:10003"}]}})

Step 6:The primary interface looks as follows:

Step 7:The secondary interface looks as follows:

Step 8:To check whether the current replica is master give the command db.ismaster() from primary:

Step 9:To check whether the current replica is master give the command db.ismaster() from secondary:

Step 10:To view the replica status of the primary:

rs.status()

 

Thats it MongoDb replica set has been configured.