flushRouterConfig
On this page本页内容
Definition
flushRouterConfig
-
flushRouterConfig
marks the cached routing table for a sharded cluster as stale, causing the next operation that requests the routing table to refresh the cache. Management of the routing table cache is generally handled automatically by the cluster. You should only need to run theflushRouterConfig
command manually in specific instances, as indicated under Considerations.
Starting in MongoDB 4.4, running flushRouterConfig
is no longer required after executing the movePrimary
or dropDatabase
commands. These two commands now automatically refresh a sharded cluster's routing table as needed when run.
Syntax
Starting in MongoDB 4.0.6 (and 3.6.11), the flushRouterConfig
is available on both mongos
and mongod
instances, and has the following syntax:
- Flush the cache for a specified collection when passed in a collection namespace parameter:
db.adminCommand(
{
flushRouterConfig: "<db.collection>"
}
) - Flush the cache for a specified database and all of its collections when passed in a database namespace parameter:
db.adminCommand(
{
flushRouterConfig: "<db>"
}
) - Flush the cache for all databases and their collections when run without a parameter or passed in a non-string scalar value (e.g.
1
):db.adminCommand("flushRouterConfig")
db.adminCommand(
{
flushRouterConfig: 1
}
)
In MongoDB 4.0.5 and earlier (and 3.6.10 and earlier), flushRouterConfig
is only available for mongos
instances and can only flush the cache for all databases and their collections:
db.adminCommand("flushRouterConfig")
db.adminCommand(
{
flushRouterConfig: 1
}
)
Considerations
Generally, a sharded cluster's routing table is automatically refreshed as needed as part of normal operation. However, you should manually issue the flushRouterConfig
command in the following instances:
- If running MongoDB 4.2 or earlier, after executing the
movePrimary
ordropDatabase
commands. - If running MongoDB 4.2.2 or earlier (or 4.0.14 or earlier), after manually clearing the
jumbo
flag from a chunk that could not be split (i.e. an indivisible chunk). See Clearjumbo
Flag for more information. - Before running the
db.collection.getShardDistribution()
command. This ensures that the command returns the most up-to-date information.