
When you deploy a MongoDB database in a mission-critical application, you can configure a replica set for high availability. A replica set offers redundancy and high availability, which reduces downtime during a disaster because there is no single point of failure. The minimum recommended configuration for a MongoDB replica set is one primary node and two secondary nodes, but replica sets can have up to 50 members. Your application writes only to the primary node, and the secondary nodes replicate the data. If the primary node fails, the replica set holds an election to choose a new primary. Applications can read data from secondaries but cannot write to them.
This guide explains how to create a MongoDB replica set. It was tested on Ubuntu 20.04, but the steps are similar for other Linux distributions.
You need three servers attached to the same Vultr VPC. Each of the servers should have:
A non-root user configured with sudo privileges
MongoDB installed and secured with a password
For clarity, this guide uses the following hostnames and private IP addresses for the servers. You should substitute these with your values.
MongoDB recommends using DNS hostnames instead of IP addresses for the replica members. Because the Vultr VPC is a private network without DNS, add the private IP addresses and hostnames to the hosts file. Repeat these steps on each server.
SSH to the server as a non-root user.
Edit the hosts file.
Locate the line below.
Enter the IP addresses and hostnames as shown under that line.
Save and close the file.
All servers in the replica set share a base64 key. Follow these steps to install the key.
Use the openssl command to generate a new key on one of the servers.
You should get a block like this. Copy this base64 key. You'll use it in the following steps.
Repeat these steps on each server.
Create a new auth_key file.
Paste your base64 key.
Save and close the file.
Set the permissions to 400, making the file read-only for the file owner and access denied for all others.
Change the owner and group to mongodb.
In this section, you'll configure the shared key, network interface, and replica set name. Repeat these sub-sections on each server.
Open mongod.conf in an editor for the following steps.
Find the security section.
Below the authorization: line, add the keyFile value as shown.
Find the network interfaces section.
Add the respective server name after the loopback interface (127.0.0.1) to each server. For example:
On server-1:
On server-2:
On server-3:
Find the replication section.
Remove the Pound comment from the replication line. Below that, add replSetName: "rs0" as shown.
Restart MongoDB on the primary node.
Restart MongoDB on the secondary nodes.
In this section, you'll add the nodes to the replica set and bootstrap the replication process.
On the primary node, log in to MongoDB.
Enter the password for your admin account and press Enter to proceed.
Run the following command to add the replica set members.
You should get the following response when the replica set starts. Notice the prompt changes to rs0 [direct: secondary] test>.
Create a sample company_db database.
You should get the following response and the prompt changes to rs0 [direct: primary] company_db>. This member is now the primary node.
Insert a sample record in a new employees collection in the company_db database.
You should get the output below.
On each secondary node, log in to MongoDB.
Enter the password for your admin account and press Enter to proceed.
You should see the prompt below, showing that the members are secondary nodes.
On each secondary node, switch to the company_db.
You should get the following output.
Run the following command on each secondary node, which allows them to accept read commands.
List the document from the employees collection.
You should get the following output on each secondary node, which shows that the replica set replicated the data to each node.
Try adding a new employee record on any secondary node.
The command should fail. Secondary nodes are read-only.
If you stop the primary server or it goes offline, the replica set elects one of the secondary nodes to be the new primary node.
For application reliability and data recovery, always consider replication for MongoDB instances. If your MongoDB replica set is working as expected, you can learn more about MongoDB and MongoDB replica sets in the MongoDB documentation Replication section.
You also need to consider how to handle failover in your client application. As explained in the documentation:
If an operation fails because of a network error, ConnectionFailure is raised, and the client reconnects in the background.
0 Comments
Be the first to comment and share your perspective with the community.