Databases Reference
In-Depth Information
Sharding a database results in its collections being stored on different shards and is a
prerequisite to sharding one of its collections.
Once you've enabled sharding on the database level, you can shard a collection by
running the
shardcollection
command:
> db.runCommand({"shardcollection" : "foo.bar", "key" : {"_id" : 1}})
Now the collection will be sharded by the
"_id"
key. When we start adding data, it will
automatically distribute itself across our shards based on the values of
"_id"
.
Production Configuration
The example in the previous section is fine for trying sharding or for development.
However, when you move an application into production, you'll want a more robust
setup. To set up sharding with no points of failure, you'll need the following:
• Multiple config servers
• Multiple
mongos
servers
• Replica sets for each shard
•
w
set correctly (see the previous chapter for information on
w
and replication)
A Robust Config
Setting up multiple config servers is simple. As of this writing, you can have one config
server (for development) or three config servers (for production).
Setting up multiple config servers is the same as setting up one; you just do it three times:
$ mkdir -p ~/dbs/config1 ~/dbs/config2 ~/dbs/config3
$ ./mongod --dbpath ~/dbs/config1 --port 20001
$ ./mongod --dbpath ~/dbs/config2 --port 20002
$ ./mongod --dbpath ~/dbs/config3 --port 20003
Then, when you start a
mongos
, you should connect it to all three config servers:
$ ./mongos --configdb localhost:20001,localhost:20002,localhost:20003
Config servers use two-phase commit, not the normal MongoDB asynchronous repli-
cation, to maintain separate copies of the cluster's configuration. This ensures that they
always have a consistent view of the cluster's state. It also means that if a single config
server is down, the cluster's configuration information will go read-only. Clients are
still able to do both reads and writes, but no rebalancing will happen until all of the
config servers are back up.
Many mongos
You can also run as many
mongos
processes as you want. One recommended setup is
to run a
mongos
process for every application server. That way, each application server
