Automatic clustering for MongoDB
This guide has been reviewed and reformatted for Ruk-Com Cloud PaaS. Screens may vary slightly by platform version.
Click or tap a screenshot to view it at its original size.
Objective
This guide explains how to use Automatic clustering for MongoDB on Ruk-Com Cloud PaaS, with ordered procedures and practical verification points.
Before you begin
- Sign in with an account permitted to manage the relevant environment.
- Confirm the target environment, region and resources before saving changes.
- Create a backup or rollback plan before changing a production system.
Ruk-Com Cloud provides automated cluster provisioning for the MongoDB stack, allowing you to createreplica setTrusted for your database with just one click. The solutions used have many benefits:
- High data redundancy and availability – Multiple copies of data on different database servers allow for a high tolerance for data loss.
- Scalability and Autodiscovery – New nodes added duringhorizontal scalingIt connects to the cluster, automatically applying all necessary modifications.
- Automatic failover – Database nodes that are temporarily unavailable or have high latency are automatically separated from the cluster and readded when connectivity is restored.
All of these benefits are available with just a few clicks within the topology wizard. Explore the steps below to enable automatic clustering for your MongoDB database in Ruk-Com PaaS.
MongoDB Auto-Clustering Specifications
Link # replica set is a group of at least three MongoDB instances that store the same data. One node of the set is considered the master node and is responsible for all write operations. Save all changes in the oplog to the remaining nodes. (Second order) can accurately reflect the primary data. If the primary is unavailable, a new entry will be automatically selected from the active secondary after a short delay.
The default value forsettingsThe automatically configured clusters are as follows:
- "chainingAllowed" : true - Allows secondary members to be replicated from other secondary chains.
- "heartbeatIntervalMillis" : 2000 - Frequency in milliseconds for the heartbeat.
- "heartbeatTimeoutSecs" : 10 - The timeout in seconds that the replica setup member waits for a heartbeat to complete before marking the appropriate node as unreachable.
- "electionTimeoutMillis" : 10000 - Timeout in milliseconds for checking if the primary member is unreachable.
- "catchUpTimeoutMillis" : -1 - Timeout in milliseconds (-1 for infinite time) for the newly recruited master to contact the member with the most recent write.
- "catchUpTakeoverDelayMillis" : 30000 – The timeout in milliseconds of the secondary node that is currently ahead of the primary node provides a trace before starting selection to become the new primary node.
Tips:
If necessary, you can manually reconfigure these settings after cluster installation using the command rs.reconfig() Check out the sections below to learn how to connect to your MongoDB cluster via SSH and run the required commands.
Another important point is security and protection from unwanted access. For this reasonauthenticationIt is an important safety assurance process. This forces members of each replica set to identify themselves during internal communications using a special authentication key file. The platform automatically applies the required configuration (in /etc/mongod.conf) and generates the key (located at /home/jelastic/mongodb.key) during cluster configuration. Also to ensure consistency. The file will be added to the link# redeploy.conf file. so that the files remain operational throughout the lifetime of the container.
MongoDB uses the WiredTiger storage engine by default. Helps ensure high efficiency. (due to non-locking algorithm) and efficient cost/resource usage. The default options for WiredTiger are optimized for running a single mongod instance per server, which is ideal for Ruk-Com PaaS containers. MongoDB uses both the WiredTiger internal cache and the filesystem cache. The internal cache size is 50% of total RAM minus 1 GB (but not less than 256 MB), while the filesystem cache runs in free memory not used by WiredTiger or other processes. For more information onWiredTiger configsPlease see the official MongoDB documentation.
Another unique feature of MongoDB auto-cluster is the automatic detection of new nodes added viahorizontal scalingand inclusion in the simulation set without any intervention.
itself. Similarly, nodes are separated from the cluster while scaling up.
Enable automatic clustering for the database.
The entire process of creating automatic MongoDB clusters can be done in just a few clicks.
1. Open the topology wizard with the New Environment button in the top left corner of the dashboard, select the MongoDB database, and enable it. Auto-Clustering through the appropriate toggle switch

Tips:
Some topology information of the MongoDB cluster is as follows:
- Automatic clustering is supported starting with version 4.x.x.
- 4 GiB of RAM (32 cloudlets) is recommended for proper operation of the replica set nodes. By default, the number of these cloudlets is dynamically increased to the scaling limit. Thereforeyou won’t be charged unless resources are actually consumed
- The minimum number of nodes required for MongoDB auto-cluster is 3.

- Configure other parameters according to your needs (link # public IPs, link # region, etc.) and click Create.
2. Wait a moment for the platform to configure the cluster for you.

3. After successful installation, you will receive an email regarding the successful configuration of the image set:

You can use these credentials to access the admin panel or to establish a connection from your application to the master node of the virtual dataset.
Tips:
As mentioned, any secondary node may become the primary node in the event of a failure. Re-selection will occur if the cluster is restarted as Therefore, it is quite possible that a new master node will emerge. Therefore the application connection string becomes invalid. To avoid these problems, the connection string should contain the hostnames of all replication set members. Model set name andread preferencesRequired to unload the master node to handle reads or to ensure high availability of the cluster and failover.
Here is an example connection string in the case of a node.js application:
client = new MongoClient(
"mongodb://admin:[email protected]:27017,
node254968-mongo-cluster.jelastic.com:27017,
node254969-mongo-cluster.jelastic.com:27017/admin",
{
useUnifiedTopology: true,
readPreference:'primaryPreferred',
replicaSet:'rs0'
}
);
Where :
- useUnifiedTopology: true - Forces mongodb to use a search engine and detect new servers.
- readPreference:'primaryPreferred' - Most read operations are performed from the primary. But if it is not available then the operation will be read from the child member.
- replicaSet:'rs0' - By default the replica set name is rs0 in Ruk-Com. You may notice the replica set name at the cluster node in the mongod.conf file or in the mongo shell prompt.
The application connections listed above are considered to be created within the one hosting platform, but if necessary you can connect external applications to the model set up throughSLBYes, in this case you must maintain connection to the master node for read/write only via link # Ruk-Com Endpoints.

If you want to read from the second sequence, you must optimize your application code to perform reading from the second sequence in a separate thread, just like you do for the main file. However, for such cases, you need to remove the replicaSet parameter from the connection string. You can view it at the email address above:
client = new MongoClient(
"mongodb://admin:[email protected]:11035/admin",
{ useUnifiedTopology: true }
);
4. By default, the auto-cluster uses the Mongo Express admin panel included with the package.

5. Additionally, you can connect to your database via mongo shell directly in your terminal. (For example, using the optionWeb SSHBuilt-in type)
mongo -u {user} -p {password} {DB_name}

Where :
- {user} – Username of the administrator. (sent to your email, default is admin)
- {password} – Password for the relevant database user. (can be found in the same email)
- {DB_name} – The name of the database you want to access (we will use admin by default).
6. You can check the replication set status with the appropriate command:
rs.status()

As you can see, the simulation set (named rs0 by default) is ready to use. You can seereplica set commandsOthers can be found in the official documents. For example, use the rs.conf() operation if you want to view the replication set configuration.
Get your own highly available MongoDB replica set with Ruk-Com Cloud.