How do mongos instances work together in a cluster?

I am trying to understand how different mongos server instances work together.

If I have 1 configserver and some fragments, for example four, each of them consists of only one node (master, of course), and you have four mongos servers ... communication between the mongos server between them? Is it possible that one mongo redirects its load to other mongos?

+7
database mongodb nosql
source share
2 answers

Short answer

Starting with MongoDB 2.4, mongos servers provide a routing service for direct read and write requests to the corresponding fragments. mongos servers discover the configuration of your shard cluster through configuration servers. You can find more information in the MongoDB documentation: Request Routing with Closed Clusters .

Longer bucket

I am trying to understand how different instances of the mongos server work.

mongos servers do not currently speak directly to each other. They coordinate activity using your configuration servers:

  • reading fragment 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 configuration servers. If you somehow lose or ruin your configuration server, you will have to merge your data and redraw your databases. The fragment cluster metadata stored on the configuration servers is the ultimate source for fragment data ranges to live on each fragment.

some fragments, for example four, each of which consists of only one node (master, of course)

Ideally, each shard should be supported by a set of replicas if you want optimal uptime. Replica sets provide automatic disaster recovery and can be very useful for administrative purposes (for example, for backing up or adding indexes offline).

Is it possible that one mongo redirects its load to other mongos?

No, mongos do not perform load balancing. A typical recommendation is to deploy one mongos for each application server.

From the point of view of the application / driver, you can specify several mongos in the connection string to recover from failure. Application drivers usually connect to the closest mongos available (by network connection time) and try to connect to it if the current mongos connection fails.

+2
source share

If you have several instances of mongos, they do not automatically balance the balance with each other. They do not even know about each other's existence.

MongoDB drivers for most programming languages ​​allow you to specify multiple mongos instances when creating a connection. In this case, the driver will usually ping all of them and connect to the device with the least delay. This is usually the one that is closest geographically. When everyone has the same distance on the network, the one that is currently the least busy will usually answer first. Then the driver will remain connected to one mongo if the program will not explicitly reconnect or the mongors can no longer be reached (in this case, the driver usually automatically selects another from the original list).

This means that using multiple instances of mongos is usually the only valid scaling method when you have a large number of clients with a low load, and not a single client with a high load. If you want your one high-performance client to use many instances of mongos, you need to implement this yourself by creating a separate connection with each instance of mongos and implementing your own mechanism for distributing requests between them.

+1
source share

All Articles