Replica Set Members in MongoDB

MongoDB is a popular NoSQL database that stores data in documents, which are JSON-like objects. MongoDB is designed to be scalable, high-performance, and flexible. MongoDB can handle various data types, such as structured, semi-structured, or unstructured data. MongoDB also supports features such as indexing, aggregation, text search, geospatial queries, and sharding.

In this article, we will understand everything about the Replica set members in MongoDB in detail along with their types and roles in MongoDB and so on.

Replica Set Members in MongoDB

A replica set in MongoDB is a group of MongoDB processes that provide redundancy and high availability. The members of a replica set are:

1. Primary Member

Whenever a replica set is initiated or a primary member is unreachable. 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.

• The primary member is the main node in a MongoDB replica set that is responsible for handling all write operations. Write operations include any changes to the data, such as insertions, updates, or deletions.
• When a write operation occurs, the primary member records this operation in the oplog. The oplog is a MongoDB collection that acts as a log of all operations that have modified the data.
• The primary member’s oplog plays a crucial role in replication. It is the source from which secondary members replicate changes.
• By default, read operations are also directed to the primary member to ensure that the most up-to-date data is read. However, this behavior can be changed by configuring read preferences to allow secondary members to handle read operations.
• A replica set can have only one primary member at any given time to ensure a consistent and reliable source of truth for all write operations.

Primary Member

Explanation of Flow Diagram

• Primary Member: This is the main component that interacts with the client application. It receives data from the client.
• Client Application: This represents the user-facing application that sends data to the primary member.
• Replication: The process of copying data from the primary member to secondary members is depicted here.
• Secondary Members: These are the components that receive replicated data from the primary member.

The flowchart visually communicates how data flows from the client application to the primary member and then is replicated to secondary members, ensuring data consistency and reliability across the system. The use of arrows indicates the direction of data flow, and the labeled boxes identify each component in the replication process. This type of diagram is commonly used to illustrate system architectures and data processes in a clear and understandable manner.

2. Secondary Member

• Secondary members are the nodes in a replica set that replicate the data from the primary member’s oplog. They apply the operations from the oplog to their own data sets to maintain an identical copy of the data.
• Secondary members can provide increased data availability. In case the primary member becomes unavailable, one of the secondary members can be elected to take over as the new primary.
• Secondary members can also improve read scalability by serving read operations, which can be particularly useful for balancing the load and reducing the read latency.
• The process of replicating data from the primary’s oplog to the secondary members is continuous and automatic, ensuring that the data across the replica set is consistent and up-to-date.

In the following three-member replica set, secondary member copies the primary member.

Secondary Member

Explanation of Flow Diagram

• The process begins with the Primary Member. The Primary Member submits an application to the Client. The Client then sends the application to the Secondary Member.
• The Secondary Member reviews the application. If the application is approved, the Secondary Member sends a replication to the Client. The Client then sends the replication to the Primary Member.
• If the application is not approved, the Secondary Member sends a rejection notice to the Client. The Client then sends the rejection notice to the Primary Member.
• The diagram also shows a Repeater. The Repeater is used to repeat the process if the application is not approved on the first try.

3. Hidden Members

Hidden members in a MongoDB replica set have a specific role and configuration. Here’s a detailed explanation:

• Role: Hidden members are part of the replica set but are not visible to client applications. They are used for specialized tasks that do not involve direct interaction with clients, such as reporting or backup.
• Election Participation: Although hidden, these members do participate in elections by casting votes, which can influence the outcome of which member becomes the primary.
• Cannot Become Primary: Hidden members are always configured with a priority of 0, which means they are ineligible to become the primary member of the replica set.
• Usage Patterns: They are particularly useful for workloads that differ from the primary workload, such as analytics or other internal processes that should not impact the performance of the primary or secondary members.
• Support for Delayed Members: Hidden members are commonly used to support delayed members, providing a historical snapshot of the data without being directly accessed by client applications.

Configuration of Hidden Members: To configure a member as hidden, you would typically set its priority to 0 and its hidden attribute to true. This is done in the MongoDB shell connected to the primary member.

Here’s an example configuration:

var c = rs.conf();
c.members[0].priority = 0; // Prevents the member from becoming primary
c.members[0].hidden = true; // Hides the member from client applications
rs.reconfig(c);

Explanation: In this configuration, the first member in the replica set’s members array is set as a hidden member. It will continue to replicate data and maintain an up-to-date dataset, but it will not serve client requests or be eligible to become the primary member. This setup is beneficial for maintaining additional copies of the data for specific purposes without affecting the overall operation and availability of the replica set. Hidden members enhance the flexibility and robustness of the MongoDB replica set architecture.

4. Delayed Member

Delayed members in a MongoDB replica set serve as a type of backup that is intentionally kept behind the current state of the dataset. Here’s a detailed explanation of their role and configuration, particularly regarding queries:

Role of Delayed Members

• Backup and Recovery: Delayed members act as a rolling backup, maintaining a historical snapshot of the dataset. This can be invaluable for recovering from human errors, such as accidental deletions or updates, as it allows administrators to revert to a previous state of the data.
• Delay Configuration: The delay is configured by setting the `slaveDelay` value, which determines how far behind the delayed member will lag in terms of applying operations from the oplog. The delay should be long enough to cover the maintenance windows but not exceed the capacity of the oplog, as this would result in lost data.

Configuration of Delayed Members

• Priority: The `priority` is set to 0 to prevent the delayed member from being elected as the primary.
• Hidden: The `hidden` value is set to `true` to hide the delayed member from client applications, ensuring that it does not receive read or write operations directly.
• Slave Delay: The `slaveDelay` option is set to the desired number of seconds to delay. For example, `c.members[0].slaveDelay = 1200` sets a 20-minute delay.

Queries on Delayed Members

• Read Operations: While delayed members are typically hidden and do not serve read operations to client applications, it is possible to configure a client to read from a delayed member by setting specific read preferences. This could be used for specific use cases where reading historical data is necessary.
• Consistency: Queries performed on a delayed member will reflect the state of the database as it was at the time determined by the delay. This means that any operations that occurred after that time will not be reflected in the query results.

Here’s an example configuration for a delayed member:

var c = rs.conf();
c.members[0].priority = 0;
c.members[0].hidden = true;
c.members[0].slaveDelay = 1200; // 20 minutes delay
rs.reconfig(c);

Explanation: This configuration ensures that the first member in the replica set configuration array is a delayed member with a 20-minute delay. It won’t participate in elections and won’t be visible to client applications for direct read/write operations. However, it will maintain a dataset state that is 20 minutes behind the primary, providing a window for recovery in case of issues with the latest data.

5. Non-Voting Members

• Non-voting members are part of the replica set but do not participate in elections. They are configured to have zero votes.
• The primary reason for having non-voting members is to add more than the maximum of seven voting members allowed in a replica set for read distribution.
• Non-voting members can still replicate data and serve read operations, which helps in scaling the read capacity of the system without affecting the election process.
• These members are particularly useful in large deployments where distributing the read load is more critical than participating in elections.

Configuring Non-Voting Members: To configure a member as non-voting, you set its votes attribute to 0 in the replica set configuration object. Here’s an example:

In this configuration, the fifth and sixth members of the replica set are set as non-voting. They will not participate in any elections to choose a new primary but will continue to replicate data and can be used to handle additional read load.

var c = rs.conf();
c.members[5].votes = 0; // Set the sixth member as non-voting
c.members[4].votes = 0; // Set the fifth member as non-voting
rs.reconfig(c);

Explanation: By carefully configuring non-voting members, administrators can ensure that their MongoDB deployment is both highly available and scalable, meeting the demands of large-scale applications. Non-voting members contribute to the robustness of the replica set by providing additional copies of the data without influencing the election outcomes.

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)

Conclusion

A conclusion part of replica set members in MongoDB is a summary of the main points and benefits of using replica sets. A possible conclusion part is Replica sets are a key feature of MongoDB that provide redundancy, high availability, and scalability for data. Replica sets consist of a primary member that receives all write operations, and one or more secondary members that replicate the primary’s data and can serve read operations. Replica sets also support automatic failover, read preference, transactions, and change streams. Replica sets are the basis for all production deployments of MongoDB and are easy to set up and manage.