Setup a MongoDB replica/sharding set in seconds

MongoDBIn the MySQL world, we’re used to playing in the MySQL Sandbox. It allows us to deploy a testing replication environment in seconds, without a great deal of effort or navigating multiple virtual machines. It is a tool that we couldn’t live without in Support.

In this post I am going to walk through the different ways we have to deploy a MongoDB replica/sharding set test in a similar way. It is important to mention that this is not intended for production, but to be used for troubleshooting, learning or just playing around with replication.

Replica Set regression test’s diagnostic commands

MongoDB includes a .js that allows us to deploy a replication set from the MongoDB’s shell. Just run the following:

At some point our mongod daemons will be running, each with its own data directory and port:

Perfect. Now we need to initialize the replicaset:

and it is done!

There are many more commands you can run, just type rstest. and then press Tab twice to get the list. Follow this link if you need more info:

What about sharding? Pretty similar:

This is the documentation link if you need more info:

It is important to mention that if you close the mongo shell where you run the commands, then all the spawned mongod will also shut down.


mtools is a collection of tools and scripts that make MongoDB’s DBA lives much easier. It includes mlaunch, which can be used to start replicate sets and sharded systems for testing.

The mlaunch tool requires pymongo, so you need to install it:

You can also use pip to install mtools:

Then, we can just start our replica set. In this case, with two nodes and one arbiter:

Done. You can also deploy a shared cluster, or a sharded replica set. More information in the following link:

Ognom Toolkit

“It is a set of utilities, functions and tests with the goal of making the life of MongoDB/TokuMX administrators easier.”

This toolkit has been created by Fernando Ipar and Sveta Smirnova, and includes a set of scripts that allow us to deploy a testing environment for both sharding and replication configurations. The main difference is that you can specify what storage engine will be the default, something you cannot do with other to methods.

We have the tools we need under “lab” directory. Most of the names are pretty self-explanatory:

So, let’s say we want a replication cluster with four nodes that will use PerconaFT storage engine. We have to do the following:

Set a variable with the storage engine we want to use:

Specify where is our mongod binary:

Start our 4 nodes replica set:

Now, just start using it:


When dealing with bugs, troubleshooting or testing some application that needs a complex MongoDB infrastructure, these processes can save us lot of time. No need of set up multiple virtual machines, deal with networking and human mistakes. Just say “I want a sharded cluster, do it for me.”

Share this post

Comment (1)

  • Kay

    Ignore my last comment (perhaps it was not even submitted?)
    I was misled by mongodb documentation saying:”replSetTest must be enabled by using –setParameter enableTestCommands=1 on the mongod command line. replSetTest cannot be enabled during run-time.”

    June 23, 2016 at 6:26 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.