MongoDB – Converting Replica Set to Standalone

This post was originally published in January 2022 and was updated in February 2025.

One of the reasons for using MongoDB is its simplicity in scaling its structure,  either as Replicaset(scale-up) or as Sharded Cluster(scale-out).

Although a bit tricky in Sharded environments, the reverse process is also feasible.

From the possibilities, you can:

• Reduce the number of shards from your Sharded Cluster as documented here.
• You can also reduce the number of nodes from a Replica Set, as detailed here.
• You can even convert from Replicaset to Sharded Cluster, and the opposite is possible to be achieved and documented at Sharded Cluster to Replicaset.

So far, so good, but if for some reason that mongo project which started as a Replica Set does not require such structure and now a Standalone server meets the requirements; 

• Can you shrink from Replica Set to a Standalone server? 

  • If possible, what is the procedure to achieve this configuration?

This blog post will walk through the necessary steps to convert a Replica Set into a Standalone server.

Observations:

Before starting the process, it is important to mention that it’s not advised to run Standalone configuration on production servers as your entire availability will only rely on a single point.

Another observation is this activity requires downtime, that’s because you will need to remove the replication parameter, which can not be at runtime.

Last note; to avoid any data change during the procedure, it’s recommended to stop writing from the application. You will need to adjust the connection string at the end of the process for the new configuration.

How To:

The testing environment is a standard Replica Set configuration with three nodes, as seen at the following replication status.

• The PRIMARY is our reliable data source; thus, it will be the Standalone server at the end of the process.

It is not needed to trigger any election process unless you have a preferred node to be the Standalone. If that’s your case and that node is not the PRIMARY yet, please make sure to make PRIMARY before starting the procedure.

That said, let’s get our hands dirty!

1) Removing the secondaries:

• From the PRIMARY node, let’s remove node 2 and 3:

Please note: Although my Replica Set comprises three nodes, you must let only the PRIMARY on replication at this step. If you have more nodes, the process is the same.

Then, the expected status should be:

 

2) Changing the configuration:

• Even though node2 and node3 are no longer part of the replication, let’s stop the mongod process. Keeping their data safe, as it can be used in a recovery scenario if necessary:

• Then, you can remove the replication parameter from PRIMARY and restart it, but first! In the configuration file:

  • Please remove or comment the lines:

If you start MongoDB via the command line, please remove the option  --replSet.

• Once changed, you can restart the mongod on PRIMARY:

3) Removing replication objects:

• Once connected to former PRIMARY, now Standalone, MongoDB will warn you with the following message:

 

That is because the node was working under a Replica Set configuration, and although it’s a Standalone now, there is the old structure existing.

For further detail, that structure resides under the local database, which holds all necessary data for replication, and for the database itself:

 

To remove that warning, you should remove the old Replica Set object on local.system.replset.

local.system.replset holds the replica set’s configuration object as its single document. To view the object’s configuration information, issue rs.conf() from mongosh. You can also query this collection directly.

However, it’s important to mention the local.system.replset is a system object, and there is no built-in role that you can use to remove objects –  Unless you create a custom role that grants anyAction on anyResource to the user, Or you grant the internal role __system to a user.

⚠️

Please note, both of that options gives access to every resource in the system and is intended for internal use. Do not use this permissions, other than in exceptional circumstances.  

For this process, we will create a new user, temporary, with __system privilege in which we can drop later after the action.

3. a) Creating the temporary user:

Confirmation output:

3. b) Removing the object:

1. First; Connect with the created user.
2. Then:

Confirmation output:

 

3. c) Dropping the temporary user:

1. Disconnect from that system user.
2. Then:

 

4) Restart the service:

 

Once reconnected, you will not see that warning again, and the server is ready!

 

5) Connection advice:

• Please make sure to adjust the connection string from the app and clients, passing only the Standalone server.

Conclusion

The conversion process, in general, is simple and should not face problems. But is essential to highlight that we strongly recommend you test and run this procedure in a lower environment. And if you plan to use it on production, please bear in mind the said before.

And if you have any questions, feel free to contact us in the comment section below!

Ready to leave MongoDB, Inc. behind? Percona is the cost-effective, enterprise-grade alternative businesses trust.