MongoDB Documentation, Release 3.0.4 11.5.15 Where does MongoDB report on connections used by mongos ? 11.5.16 What does writebacklisten in the log mean? 11.5.17 How should administrators deal with failed migrations? 11.5.18 What is the process for moving, renaming, or changing the number of con- fig servers? 11.5.19 When do the mongos servers detect config server changes? 11.5.20 Is it possible to quickly update mongos servers after updating a replica set configuration? 11.5.21 What does the maxConns setting on mongos do? Chapter 11. Frequently Asked Questions 766 In this case, set maxIncomingConnections to a value slightly higher than the maximum number of connections that the client creates, or the maximum size of the connection pool. This is particularly useful for a mongos if you have a client that creates multiple connections and allows them to timeout rather than closing them. The maxIncomingConnections option limits the number of connections accepted by mongos . The mongos instances will detect these changes without intervention over time. However, if you want to force the mongos to reload its configuration, run the flushRouterConfig command against to each mongos directly. mongos updates its cache lazily by issuing a request to a shard and discovering that its metadata is out of date. There is no way to control this behavior from the client, but you can run the flushRouterConfig command against any mongos to force it to refresh its cache. mongos instances maintain a cache of the config database that holds the metadata for the sharded cluster . This metadata includes the mapping of chunks to shards . See Sharded Cluster Tutorials (page 690) for information on migrating and replacing config servers. Failed migrations require no administrative intervention. Chunk migrations always preserve a consistent state. If a mi- gration fails to complete for some reason, the cluster retries the operation. When the migration completes successfully, the data resides only on the new shard. These messages are a key part of the sharding infrastructure and should not cause concern. The writeback listener is a process that opens a long poll to relay writes back from a mongod or mongos after migrations to make sure they have not gone to the wrong server. The writeback listener sends writes back to the correct server if necessary. Connect to the mongos with the mongo shell, and run the following command: db._adminCommand("connPoolStats");