Docs Home → Develop Applications → MongoDB Manual
FAQ: Sharding with MongoDB![](/docs/v5.3/assets/link.svg)
On this page
- Is sharding appropriate for a new deployment?
- Can I select a different shard key after sharding a collection?
- Why are my documents not distributed across the shards?
- How does
mongos
detect changes in the sharded cluster configuration? - What does
writebacklisten
in the log mean? - How does
mongos
use connections?
This document answers common questions about Sharding. See also the Sharding section in the manual, which provides an overview of sharding, including details on:
Is sharding appropriate for a new deployment?![](/docs/v5.3/assets/link.svg)
Sometimes. However, if your data set fits on a single server, you should begin with an unsharded deployment as sharding while your data set is small provides little advantage .
Can I select a different shard key after sharding a collection?![](/docs/v5.3/assets/link.svg)
Your options for changing a shard key depend on the version of MongoDB that you are running:
Starting in MongoDB 5.0, you can reshard a collection by changing a document's shard key.
Starting in MongoDB 4.4, you can refine a shard key by adding a suffix field or fields to the existing shard key.
In MongoDB 4.2 and earlier, the choice of shard key cannot be changed after sharding.
In MongoDB 4.2 and earlier, if you must change a shard key after sharding a collection and cannot upgrade, the best option is to:
dump all data from MongoDB into an external format.
drop the original sharded collection.
configure sharding using a more ideal shard key.
pre-split the shard key range to ensure initial even distribution.
restore the dumped data into MongoDB.
Tip
See also:
Why are my documents not distributed across the shards?![](/docs/v5.3/assets/link.svg)
The balancer starts distributing data across the shards once the distribution of chunks has reached certain thresholds. See Migration Thresholds.
In addition, MongoDB cannot move a chunk if the number of documents in the chunk exceeds a certain number. See Maximum Number of Documents Per Chunk to Migrate and Indivisible/Jumbo Chunks.
How does mongos
detect changes in the sharded cluster configuration?![](/docs/v5.3/assets/link.svg)
mongos
instances maintain a cache of the config database that holds the metadata for the sharded cluster.
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.
What does writebacklisten
in the log mean?![](/docs/v5.3/assets/link.svg)
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.
How does mongos
use connections?![](/docs/v5.3/assets/link.svg)
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
mongosh
to the mongos
, and run the
connPoolStats
command:
db.adminCommand("connPoolStats");
See the System Resource Utilization section of the UNIX ulimit
Settings
document.