Replica Sets: Member Roles and Types

MongoDB replica sets are a powerful way to ensure high availability and data redundancy in your database environment.

While we won’t delve into all the intricate configuration options here, let’s explore some key member roles and types that allow you to shape your replica set’s behavior according to your needs.

Priority: Defining Leadership

In a basic replica set configuration, all members have equal priority, and primary election can occur randomly. However, by adjusting the priority of individual members, you can influence the election process. Consider this example:

"members": [
  { "_id": 1, "host": "localhost:27021", "priority": 1000 },
  { "_id": 2, "host": "localhost:27022", "priority": 1 },
  { "_id": 3, "host": "localhost:27023", "priority": 0 }
]

Here, node 1 is set with the highest priority (1000), making it the preferred choice for primary. Node 2 has a priority of 1, and node 3 has a priority of 0, making it ineligible for primary election. This setup ensures that unless there’s a significant issue, node 1 will be elected primary.

Voting Nodes: Power and Responsibility

Each replica set member can be configured as a voting node or a non-voting node. Setting a node’s votes property to 1 (or true) marks it as voting as voting node while 0 (or false) marks the node as non-voting. Nodes with a priority greater than 0 must be able to vote. A replica set can have up to 7 voting members out of a total of 50. Nodes with priority of 0 should also have votes set to 0.

Hidden Nodes: A Silent Presence

Hidden nodes are a special type of node with a priority of 0 but still retain voting capability. They mirror the primary’s data and can participate in elections. These nodes are perfect for tasks like backups or read-only reporting, as they have the data without adding load to the set.

To create a hidden node:

{
  "_id" : 123,
  "host" : "hostname:port",
  "priority" : 0,
  "hidden" : true
}

Hidden nodes are discreet contributors, ready to assist in maintaining data integrity and availability.

Delayed Nodes: Time Travel for Data Recovery

Delayed nodes take the concept of hidden nodes a step further. By introducing a delay in processing operations from the primary, these nodes maintain a historical copy of data. For instance, a delayed node with a secondaryDelaySecs setting of 3600 seconds (1 hour) offers a snapshot of the database state an hour ago. This can be invaluable for disaster recovery, such as recovering from accidental deletions.

{
  "_id" : 123,
  "host" : "hostname:port",
  "priority" : 0,
  "secondaryDelaySecs" : 3600,
  "hidden" : true
}

Arbiters: Balancing Majority without Data Overhead

In replica sets, a majority is required for elections. However, maintaining a full secondary node for the sole purpose of ensuring a majority can be costly. This is where “arbiter” nodes come in. Arbiters have voting rights but lack a copy of the primary’s data, and thus cannot become a primary themselves. They are lightweight solutions for maintaining majority without added data overhead.

To add an arbiter:

rs.addArb("hostname.example.com:27017")

While arbiters are generally not recommended due to their limited role, they can be valuable in certain scenarios, especially across data centers where data synchronization might be challenging.

Conclusion

In MongoDB replica sets, the roles and types of members play a pivotal role in shaping the set’s behavior and capabilities. By strategically configuring priorities, votes, hidden nodes, delayed nodes, and arbiters, you can tailor your replica set to your application’s needs, ensuring high availability, disaster recovery, and efficient resource utilization. Always refer to the official documentation for detailed information and best practices.

Learn Mongo