Risk factor analysis in mongo db

Question

I am trying to make mongodb set-up, I am trying to analyze risk factor involved in it.

My configuration in testing environment is

Routing server------> Config Server ------- > Shard01
                                              Shard02
                                              Shard03

My routing server and config server is running on same machine. Shard01, Shard02, Shard03 are running on three different machine respectively. I want to analyze what all risk factors are involved in this system. For example, one scenario is if any Shard machine is down application will stop?

Answer 1

1. It is a Very Bad Idea (TM) to have only one config server. For production environments, always, always, always use three config servers. Reason: Without a config server, the cluster basically becomes useless, since the query router gets the information about which key range lives on which shard from the config servers. (Setting aside mongos' metadata caching, as this only delays the problem). Note: If doing otherwise, proceed at your own risk.
2. It is a very bad idea to have the config server and the query router running on the same machine. Under heavy load, these machines need to compete for network IO. While this is a rare case, it still might happen. It makes (a lot) more sense to put a query router on each application server: it reduces the network latency (one hop less until the data is reached), the individual mongos can't be overloaded and you don't need to run your mongos on the config server. ;) Seriously, it is the suggested and well proven setup.
3. It is an AWFUL idea to run a shard as a standalone instance. If your primary shard (the shard holding the unsharded collections, including system) fails, you are in big trouble. You should always use replica sets as shards. Note: If doing otherwise, proceed at your own risk.

A less well known feature of the MongoDB drivers is that you can configure them to use multiple mongos instances. If the first one fails, the next one is tried. So, with multiple mongos (one per application server), proper data source configuration, three config servers and replica sets as shards there is no single point of failure (node wise).