2

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.

1

How it is done

Basically, it is easy:

  1. Set up three(!) config servers
  2. 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
  3. 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.
  4. Connect to the mongos instance.
  5. Add the shard via the sh.addShard() command.
  6. Done. Start sharding the collections as needed.

Some advice

  1. 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.
  2. 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.
  3. 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.
1
  • Thanks for this, I ended up finding someone on IRC that gave a response along the same lines. I'm happy to say I haven't had an issue yet scaling my cluster :D
    – firrae
    Oct 1 '15 at 0:32
-1

Here is the mongodb documentation on how to covert replica set to a sharded cluster. http://docs.mongodb.org/manual/tutorial/convert-replica-set-to-replicated-shard-cluster/

You can follow these steps except creating and adding replica set/sets you can add your standalone instance to the sharded cluster.

2
  • Try to provide more than just a link-only answer. If the link changes or goes dead then this answer becomes useless. May 19 '15 at 14:20
  • Also they are asking for help with setting up a shared cluster from a stand alone instance. Not a replica set. :) Jan 6 '18 at 5:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.