MongoDB load balancing and failover of query routers

Question

I'm wondering how load balacing and failover between client and query routers work in MongoDB. I haven't found any matching documentation so far. Everyone says it's not relevant and I don't think so. Every piece of software / hardware can die and there'll be always a reason why you can't bring it up immediately again.

The situation is very simple. Assuming a usual setup with sharded replicat sets, a client connects to a query router and performs operations. What happens if the query router dies? Is there an intended way for automatic failover to a second query router? Or for load balancing between 2 query routers?

Thanks for you help, Dirk

Answer 1

Everyone says it's not relevant and I don't think so.

And your right so. Failover of mongos instances is very important, without proper architecture to deal with this you could have a serious failure in your app. It also breaks the high availability of MongoDB.

What happens if the query router dies?

This is where you should really be putting in a seed list into the connection string in your driver, in this case the driver will do something along the lines of what it does with replicas and try and connect to other members on the list to resume as normal.

Is there an intended way for automatic failover to a second query router?

Provided you supply more mongos instance IPs to your applications configuration this should be pretty automated.

Or for load balancing between 2 query routers?

You can go that route as well if you want a only supply a single IP, but then you have to worry about that load balancer, and so on, and so forth...

Answer 2

There are some drivers (i am sure in JAVA and Python) which supports automatic failover and reconnection if you provide an appropriate list of mongos processes for them. In the JAVA driver also some roundrobin balancing built in, but these features not exists in all drivers. for example C++ driver do not have either. Check for the functionality of the given driver you plan to use.

If you have a balanced application tier above the database, you can place one mongos on each application server and use it dedicated for that. In this case failure of a single mongos will affect only that application server, and ofcourse this will be out while mongos not functioning. This architecture resolves the balancing and the HA issue at once.

Oherway you can use for example HAProxy for loadbalancing in front of mongos processes, but there is no HA functionality built in the mongos processes themselfs so if one go out it will affect all of your API servers with this architecture.