Sharding - MongoDB in Action - page 217

Failure of a config server
A sharded cluster requires three config servers for normal operation, but up to two of
these can fail. Whenever you have fewer than three config servers, your remaining
config servers will become read-only, and all splitting and balancing operations will be
suspended. Note that this won't negatively affect the cluster as a whole. Reads and
writes to the cluster will still work, and the balancer will start from where it left off
once all three config servers are restored.
To restore a config server, copy the data files from an existing config server to the
failed config server's machine. Then restart the server. 18

Failure of a mongos
The failure of a mongos process is nothing to worry about. If you're hosting mongos on
an application server, and mongos fails, then it's likely that your application server has
failed, too. Recovery in this case simply means restoring the server.
Regardless of how mongos fails, the process has no state of its own. This means that
recovering a mongos is a simple matter of restarting the mongos process and pointing it
at the config servers.

9.6 Summary

Sharding is an effective strategy for maintaining high read and write performance on
large data sets. MongoDB's sharding works well in numerous production deploy-
ments, and can work for you, too. Instead of having to worry about implementing
your own half-baked, custom sharding solution, you can take advantage of all the
effort that's been put into MongoDB's sharding mechanism. If you follow the advice
in this chapter, paying particular attention to the recommend deployment topologies,
the strategies for choosing a shard key, and the importance of keeping data in RAM ,
then sharding will serve you well.

18

As always, before you copy any data files, make sure you either lock the mongod (as described in chapter 10)
or shut it down cleanly. Never copy data files while the server is live.