In the previous articles we have discussed many aspects of replica set in mongodb. And in those articles we have talked many things about members. So, what are these members? What is their purpose? Let us discuss about these things in this article.
What are members in mongodb?
In short terms the members in mongodb are the mongod processes which need to be executed in replica set. Now, in general there are only 2 members:
Primary:
As per mongodb.org the primary members receive all write operations.
Secondary:
Secondaries replicate operations from the primary to maintain an identical data set. Secondaries may have additional configurations for special usage profiles. We can use maximum of 12 members in a replica set. From which only 7 can vote. So now the question arises: why do members need to vote?
Selection for primary member:
Whenever a replica set is initiated or a primary member is unreachable. Or in simple terms if there is no primary member present then the election is commenced to choose a primary member from the secondary members. Although there are a few types of members than before 2, we will talk about them later.
Primary member:
The primary member 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. All members of the replica set can accept read operations. But, by default an application directs its read operations to the primary member. The replica set can have at most one primary.
In the following three-member replica set, the primary accepts all write operations. Then the secondaries replicate the oplog to apply to their data sets.
Secondary member:
A secondary member maintains a copy of the primary’s data set. To replicate data, a secondary applies operations from the primary’s oplog to its own data set in an asynchronous process. A replica set can have one or more secondary member. Data can’t be written to secondary, but data can be read from secondary members. In case of the primary member’s absence a secondary member can be primary through election.
In the following three-member replica set, secondary member copies the primary member.
Hidden members:
Except the before two members, there are other members that comes into a replica set. One of them is a hidden member. Hidden members cannot become primary and are invisible to client applications. Hidden members do vote in elections. Hidden members are good for workloads with different usage patterns from the other members in the replica set. Also they must always be priority 0 members and so they cannot become primary. The most common use of hidden nodes is to support delayed members. To configure a secondary member as hidden, set its priority value to 0 and set its hidden value to true in its member configuration.
To configure a hidden member, use the following sequence in a mongo shell connected to the primary, specifying the member to configure by its array index in the members array:
c.members[0].priority = 0 c.members[0].hidden = true
Delayed member:
Another member is delayed member. Delayed members also copies data from the dataset. But as the name suggests the copied dataset is delayed than actual timing. As for example we can say that if we have an application to determine the current time. Then if the current time is 09:00 and a member has a delay of an hour, the delayed member has no operation more recent than 08:00.
Because delayed members are a “rolling backup” or a running “historical” snapshot of the data set, they may be of help to recover from various kinds of human error. Delayed members apply operations from the oplog on a delay. Must be is equal to or greater than your maintenance windows. Must be smaller than the capacity of the oplog. For more information on oplog size.
To configure a delayed secondary member, set its priority value to 0, its hidden value to true, and its slaveDelay value to the number of seconds to delay.
c.members[0].priority = 0 c.members[0].hidden = true c.members[0].slaveDelay = 1200
Non-voting members:
There is a lot of talk about election in replica sets. So, in the election few of the members participate and give votes to determine primary member. But there are also a few members, who do not participate in voting. These members are called non-voting members. Non-voting members allow you to add additional members for read distribution beyond the maximum seven voting members.
To configure a member as non-voting, set its votes value to 0.
c.members[5].votes = 0 c.members[4].votes = 0
Priority in members:
These are the basic few members that we have to keep in mind for replica sets. To get here we have seen many operations as priority. Priority is indeed a very important thing to discuss about. The priority settings of replica set members affect the outcomes of elections for primary. The value of the member’s priority setting determines the member’s priority in elections. The higher the number, the higher the priority.
Configuring member priority:
To modify priorities, we have to update the members array in the replica configuration object. The value of priority can be any floating point number between 0 and 1000. The default value for the priority field is 1.Adjust priority during a scheduled maintenance window. Reconfiguring priority can force the current primary to step down, leading to an election. To block a member from seeking election as primary, assign the priority of that member to 0.
We can complete configuring priority in simple 3 steps. Let us look at them:
- Copy the replica set configuration to a variable.
In the mongo shell, use rs.conf() to retrieve the replica set configuration and assign it to a variable. For example:
c = rs.conf()
- Change each member’s priority value.
Change each member’s priority value, as configured in the members array.
c.members[0].priority = 0.5 c.members[1].priority = 2
This sequence of operations modifies the value of c to set the priority for the first two members defined in the members array.
- Assign the replica set the new configuration.
Use rs.reconfig() to apply the new configuration.
rs.reconfig(c)
In this article we have discussed about members in replica set. We can say now that members are the very basis of replica sets. The more we will get to know about the members, our control will be swifter in handling data in mongodb.
| Reference: | Replica Set Members in Mongodb from our JCG partner Biswadeep Ghosh at the Phlox Blog blog. |
