Troubleshoot Sharded Clusters¶

On this page

Config Database String Error
Cursor Fails Because of Stale Config Data
Avoid Downtime when Moving Config Servers

This section describes common strategies for troubleshooting sharded cluster deployments.

Config Database String Error¶

Changed in version 3.2: Starting in MongoDB 3.2, config servers are deployed as replica sets by default. The mongos instances for the sharded cluster must specify the same config server replica set name but can specify hostname and port of different members of the replica set.

If using the deprecated topology of three mirrored mongod instances for config servers, mongos instances in a sharded cluster must specify identical configDB string.

Cursor Fails Because of Stale Config Data¶

A query returns the following warning when one or more of the mongos instances has not yet updated its cache of the cluster’s metadata from the config database:

could not initialize cursor across all shards because : stale config detected

This warning should not propagate back to your application. The warning will repeat until all the mongos instances refresh their caches. To force an instance to refresh its cache, run the flushRouterConfig command.

Avoid Downtime when Moving Config Servers¶

Use CNAMEs to identify your config servers to the cluster so that you can rename and renumber your config servers without downtime.

← Shard GridFS Data Store Sharding Reference →

Was this page helpful?

Yes No

Thank you for your feedback!

We're sorry! You can Report a Problem to help us improve this page.