How do mongos instances work together in a cluster?

Question

I'm trying to figure out how different instances of mongos server work together.

If I have 1 configserver and some shards, for example four, each of them composed by only one node (a master of course), and have four mongos server... do the mongos server communicate between them? Is it possible that one mongos redirect its load to another mongos?

Answer 1

When you have multiple mongos instances, they do not automatically load-balance between each other. They don't even know about each others existence.

The MongoDB drivers for most programming languages allow to specify multiple mongos instances when creating a connection. In that case the driver will usually ping all of them and connect to the one with the lowest latency. This will usually be the one which is closest geographically. When all have the same network distance, the one which is least busy right now will usually respond first. The driver will then stay connected to that one mongos, unless the program explicitely reconnects or the mongos can no longer be reached (in that case the driver will usually automatically pick another one from the initial list).

That means using multiple mongos instances is normally only a valid method for scaling when you have a large number of low-load clients, not one high-load client. When you want your one high-load client to make use of many mongos instances, you need to implement this yourself by creating a separate connection to each mongos instance and implement your own mechanism to distribute queries among them.

Answer 2

Short answer

As of MongoDB 2.4, the mongos servers only provide a routing service to direct read/write queries to the appropriate shard(s). The mongos servers discover the configuration for your sharded cluster via the config servers. You can find out more details in the MongoDB documentation: Sharded Cluster Query Routing.

Longer scoop

I'm trying to figure out how different instances of mongos server work togheter.

The mongos servers do not currently talk directly to each other. They do coordinate activity some activity via your config servers:

• reading the sharded cluster metadata
• initiating a balancing round (any mongos can start a balancing round, but only one round can be active at a time)

If I have 1 configserver

You should always have 3 config servers in production. If you somehow lose or corrupt your config server, you will have to combine your data and re-shard your database(s). The sharded cluster metadata saved on the config servers is the definitive source for what sharded data ranges should live on each shard.

some shards, for example four, each of them composed by only one node (a master of course)

Ideally each shard should be backed by a replica set if you want optimal uptime. Replica sets provide for auto-failover and can be very useful for administrative purposes (for example, taking backups or adding indexes offline).

Is it possible that one mongos redirect its load to another mongos?

No, the mongos do not perform any load balancing. The typical recommendation is to deploy one mongos per app server.

From an application/driver point of view you can specify multiple mongos in your connect string for failover purposes. The application drivers will generally connect to the nearest available mongos (by network ping time), and attempt to reconnect to in the event the current mongos connection fails.