Standalone MongoDB to MongoDB Shard Setup I'm learning MongoDB currently so maybe the title of this question is worded poorly, but I'm looking to understand the scaling of Mongo better. I did some research on what DB would be best for my current needs and currently a standalone instance of Mongo fills that, but I'd like to plan for the future.

I'm trying to figure out the process of scaling up MongoDB. In my case the issue I foresee is an extremely large number of documents requiring bigger servers. I began to look up information on ways to solve this and the best way I could see was using Mongo's sharing capability. The only issue though is I don't understand the process of going from standalone to shards. Is there a document that can explain the process or is there a better way to handle such scaling? 

Any help is appreciated while I'm learning this.
How it is done

Basically, it is easy:


Set up three(!) config servers
Start a mongos query router and have the --configdb option string point to the three config servers. Note: the string has to be identical on all mongos
Restart your going to be shard with the shardsvr option set. This step isn't strictly necessary, but best practise. What this basically does is that mongod will start on a different port (27108), preventing accidental (and potentially problematic) direct access to the shard.
Connect to the mongos instance.
Add the shard via the sh.addShard() command.
Done. Start sharding the collections as needed.


Some advice


If it is foreseeable that you will have to scale out, I would go into production with a sharded cluster consisting of a single shard right away. This makes scaling out much easier and faster when you reach the limits of your single shard – simply fire up another shard, add it using the addShard command and you are done.
Always, always, always let your shards consist of replica sets. And from personal experience with one of my customers: While using a replica set with only two data bearing nodes and an arbiter is possible, I would not advice doing so. The reason for this advice is that if you are doing maintenance on one of the data bearing nodes, there is no failover possibility in case the other node fails. So your shards should consist of replica sets with (at least) three data bearing, non-hidden and non-delayed nodes with default priority.
While MongoDB is pretty easy to fire up and maintain in a standalone and even replica set configuration, things tend to get a lot more complicated when you start to shard in a production environment. Make sure you have a MongoDB specialist at hand when going into production.