Connect an application to a MongoDB cluster
The Bitnami Multi-Tier Solution for MongoDB creates a replica set consisting of one primary and a variable number of secondary nodes (which could include an optional arbiter node). In the event of primary node failure, a secondary node will be elected as the new primary and take the place of the original primary. This ensures data availability and redundancy for connected applications.
When connecting an application to the Bitnami Multi-Tier Solution for MongoDB, keep the following points in mind:
Construct the MongoDB connection URI so that it contains the IP addresses of all the nodes in the cluster. This ensures that even if the primary node fails and is replaced by a secondary node, the application will still be able to read data from, and write data to, the MongoDB cluster.
For details on how to pass the MongoDB connection string to your application, refer to the documentation for your application’s MongoDB driver. As an example, here is the connection string passed to the PHP MongoDB driver:
<?php $client = new \MongoDB\Client("mongodb://username:firstname.lastname@example.org:27017,10.0.0.5:27017,10.0.0.6:27017,10.0.0.7:27017/?replicaSet=replicaset"); ...
Read more about the MongoDB standard connection string format in the MongoDB documentation.
Ensure that the application is able to connect to each cluster node using its public or private IP address. To ensure connectivity, you have the following use cases and solutions (these are shown in order of preference, from the most secure to the least secure):
- Option 1: Host the application in the same network as the MongoDB cluster so that it can address each node using its private IP address. This is the recommended configuration for production environments.
- Option 2: Host the application in a different network and connect to the database server using the Virtual Private Cloud (VPC) Network peering. Check the instructions given in the Connect Google Cloud Platform instances in different private networks using VPC network peering guide.
- Option 3: Host the application in a different server for development purposes; we recommend connecting to the database cluster through an SSH tunnel. Refer to the FAQ for more information on this.
- Option 4: Open specific ports and assign public IP addresses to the cluster nodes so that the application can address each node using its public IP address. In this case, it is strongly recommended to specify a trusted IP addresses range. Check how to configure the appropriate firewall rules section to know how to allow traffic to your server only from trusted sources.