Sharding - MongoDB in Action - page 215

the sharded collection you dumped. For example, suppose that foo is a sharded col-
lection. You must dump foo by connecting to mongos with mongodump :
$ mongodump -h arete --port 40000 -d cloud-docs -c foo
connected to: arete:40000
DATABASE: cloud-docs to dump/cloud-docs
cloud-docs.foo to dump/cloud-docs/foo.bson
100 objects
This will dump the collection to a file called foo.bson. You can then restore that file
using mongorestore :
$ mongorestore -h arete --port 40000 -d cloud-docs -c bar
Tue Mar 22 12:06:12 dump/cloud-docs/foo.bson
Tue Mar 22 12:06:12 going into namespace [cloud-docs.bar]
Tue Mar 22 12:06:12 100 objects found
Once you've moved the data into an unsharded collection, you're now free to drop
the old sharded collection, foo .
B ACKING UP A SHARDED CLUSTER
To b a ck u p a s h a r d e d c lu s t e r, y o u n e e d a c o p y o f t h e c o n f i g d a t a , a n d y o u n e e d a
copy of the data from each shard. There are two ways to get this data. The first is to
use the mongodump utility. Dump the data from one of the config servers and then
dump the data from each individual shard. Alternatively, you can run mongodump
through the mongos router and dump the entire sharded collection, including the
config database, at once. The main problem with this strategy is that the sharded clus-
ter's total data might be too large to dump to a single machine.
Another common way to back up a sharded cluster is to copy the data files from
one member of each shard and from one config server. This backup procedure is
described in the next chapter for an individual mongod process and replica set. You
merely need to apply that process to each shard and to one config server.
Regardless of the backup procedure you decide upon, you need to ensure that
chunks aren't in the process of moving when you back up the system. This means stop-
ping the balancer process.
Stopping the balancer
At the moment, disabling the balancer is a matter of upserting a document into the
config database's settings collection:
> use config
> db.settings.update({_id: "balancer"}, {$set: {stopped: true}}, true);
Do be careful here: once you've updated the config, the balancer still might not be
done working. Before you proceed to back up the cluster, you'll need to make sure
that the balancer has completed the latest balancing round. The best way to do this is
to check the locks collection for the entry with an _id value of balancer and ensure
that its state is 0. Here's a sample entry from that collection:
> use config
> db.locks.find({_id: "balancer"})