There is no automatic support in MongoDB for changing a shard key
after sharding a collection. This reality underscores
the importance of choosing a good shard key. If you
must change a shard key after sharding a collection, the best option is to:

mongos updates its cache lazily by issuing a request to a
shard and discovering that its metadata is out of date. To force the
mongos to reload its cache, you can run the
flushRouterConfig command against each mongos
directly.

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.

These messages are a key part of the sharding infrastructure and should
not cause concern.

Each mongos instance maintains a pool of connections to the
members of the sharded cluster. Client requests use these connections
one at a time; i.e. requests are not multiplexed or pipelined.

When client requests complete, the mongos returns the
connection to the pool. These pools do not shrink when the number of
clients decreases. This can lead to an unused mongos with a
large number of open connections. If the mongos is no longer
in use, it is safe to restart the process to close existing connections.

To return aggregated statistics related to all of the outgoing
connection pools used by the mongos, connect a
mongo shell to the mongos with , and run the
connPoolStats command: