MongoDB Documentation, Release 3.0.4 Shard Status Config Servers Tip Read and Write Operations on Config Servers MongoDB reads data from the config server in the following cases: MongoDB also uses the config server to manage distributed locks. When writing to the three config servers, a coordinator dispatches the same write commands to the three config servers and collects the results. Differing results indicate an inconsistent writes to the config servers and may require manual intervention. Once the config servers become inconsistent, the balancer will not perform any chunk migration and mongos will not perform auto-splits of chunks. MongoDB only writes data to the config server when the metadata changes, such as Config servers store the cluster’s metadata in the config database (page 737). The mongos instances cache this data and use it to route reads and writes to shards. Use CNAMEs to identify your config servers to the cluster so that you can rename and renumber your config servers without downtime. Each sharded cluster must have its own config servers. Do not use the same config servers for different sharded clusters. Warning: If your cluster has a single config server, then the config server is a single point of failure. If the config server is inaccessible, the cluster is not accessible. If you cannot recover the data on a config server, the cluster will be inoperable. Always use three config servers for production deployments. For testing purposes you may deploy a cluster with a single config server. But to ensure redundancy and safety in production, you should always use three. A production sharded cluster has exactly three config servers. All config servers must be available to deploy a sharded cluster or to make any changes to cluster metadata. Config servers do not run as replica sets. Config servers are special mongod instances that store the metadata (page 689) for a sharded cluster. Use the sh.status() method in the mongo shell to see an overview of the cluster. This reports includes which shard is primary for the database and the chunk distribution across the shards. See sh.status() method for more details. • after a chunk migration (page 685), or • after a chunk split (page 687). • A new mongos starts for the first time, or an existing mongos restarts. • After change in the cluster metadata, such as after a chunk migration. Chapter 10. Sharding 670