Deploy a Production-Ready MongoDB Cluster in just a Few Clicks

Vikram Vaswani

Vikram Vaswani


Share this article

Do you need a scalable, production-ready MongoDB cluster for your application? Does it need to support replication and high availability out of the box? Does it need to be secure by default but simple to set up?

If your answers to the above questions are "yes", then meet Bitnami's MongoDB with Replication solution. This solution, now available in the Azure Marketplace and Google Compute Platform, gives you a ready-to-use MongoDB replica set that provides redundancy and high availability in production environments.

Cluster topology

Bitnami's MongoDB with Replication cluster is configured following current best practices for security and scalability. The solution supports MongoDB replication out of the box, ensuring that copies of your data are held on separate servers. By replicating the data across multiple nodes, this solution significantly reduces the risk of application failure and data loss.

Deploying the Solution

To deploy the MongoDB cluster, sign in to the Google Cloud Console or Azure Marketplace, choose the number of nodes you need (the default is 3) and deploy the cluster. Once the cluster is successfully deployed, you can log in to the primary node via SSH (Microsoft Azure instructions and Google Cloud Platform instructions) and run the commands below to check the status of the cluster (replace PASSWORD with your MongoDB administrative password):

$ mongo admin --username root --password PASSWORD
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27017/admin
MongoDB server version: 3.6.3
rs0:PRIMARY> rs.status()

Cluster status

Check the members section of the output. It should show you the role of the current node (in this case, it's the primary node) as well as the roles and IP addresses of the other members of the cluster. If you see output similar to the above, your cluster is good to go!

Understanding the Default Network Configuration and Security

The cluster operates on the standard MongoDB port 27017. For security reasons, this port is not open for external connections by default. To allow external access to the MongoDB cluster, you can use virtual network peering, an SSH tunnel or an IP address whitelist. Refer to our documentation (Microsoft Azure instructions and Google Cloud Platform instructions) for more information on these options.

The main MongoDB configuration file is at /opt/bitnami/mongodb/conf/mongodb.conf, and the MongoDB logs are stored in the /opt/bitnami/mongodb/logs/mongodb.log file.

By default, Bitnami's MongoDB with Replication solution is configured with n1-standard-2 instances on Google Cloud Platform (2vCPU, 7.5 GB RAM) and D1 V2 instances on Microsoft Azure (1vCPU, 3.5 GB RAM). Of course, you can change these default instance types when deploying the solution, and you can also add nodes to the cluster later.

Understanding Data Replication

In Bitnami's MongoDB with Replication solution, one node in the cluster is designated as the primary node and receives all write operations, while other nodes are designated as secondary nodes and asynchronously replicate the operations performed by the primary node on their own copies of the data set.

When deploying the solution, you can specify the number of nodes you need. If you select an even number of nodes, it's a good idea to add an arbiter node. Arbiter nodes do not host any data; their function is to provide an additional vote in replica set elections.

Testing Redundancy and Retrieving Metrics

A key feature of Bitnami's MongoDB with Replication solution is high availability. In case the primary node fails, the secondary nodes and arbiters will elect a new primary automatically to ensure that writes continue without interruption. This provides redundancy and ensures minimal downtime for your application.

To see this in action, connect to the primary node and use the rs.status() command to check that there are two secondary nodes currently connected.

Testing redundancy

NOTE: Before proceeding with the next step, Microsoft Azure users should ensure that at least one of their secondaries has a public IP address and that they are able to connect to it using SSH.

Now, turn off the primary node, then connect to either of the secondary nodes via SSH and run the rs.status() command again. You will see that the original primary node is now marked "unhealthy" and one of the secondary nodes is now the new primary node.

Testing redundancy

To use the cluster with your application, configure your application's MongoDB driver with the IP addresses of all the nodes in the cluster (barring arbiter nodes). This will allow the application to connect to any of the nodes in the cluster.

You can use the mongostat command to keep track of server and cluster metrics, such as the number of queries, connections, memory usage and more. Here's an example:

Cluster metrics

You can also use the mongotop command to see read/write statistics by collection.

A MongoDB replica set with high availability lets you run your application without worrying about data loss or downtime. Add Bitnami's up-to-date images and support for multiple cloud platforms, and you've got a solution that's ideal for production environments.

Find out more about configuring and using Bitnami's MongoDB with Replication solution in our docs and tweet @bitnami to tell us what you liked (or didn't like) about it!