Sharded Cluster Components

A MongoDB sharded cluster consists of the following components:

  • shard: Each shard contains asubset of the sharded data. As of MongoDB 3.6, shards must be deployedas a replica set.
  • mongos: The mongos acts as aquery router, providing an interface between client applications and thesharded cluster.
  • config servers: Configservers store metadata and configuration settings for the cluster. Asof MongoDB 3.4, config servers must be deployed as a replica set (CSRS).

Production Configuration

In a production cluster, ensure that data is redundant andthat your systems are highly available. Consider the followingfor a production sharded cluster deployment:

Replica Set Distribution

Where possible, consider deploying one member of each replica setin a site suitable for being a disaster recovery location.

Note

Distributing replica set members across two data centers providesbenefit over a single data center. In a two data centerdistribution,

  • If one of the data centers goes down, the data is still availablefor reads unlike a single data center distribution.
  • If the data center with a minority of the members goes down, thereplica set can still serve write operations as well as readoperations.
  • However, if the data center with the majority of the members goesdown, the replica set becomes read-only.

If possible, distribute members across at least three data centers.For config server replica sets (CSRS), the best practice is todistribute across three (or more depending on the number of members)centers. If the cost of the third data center is prohibitive, onedistribution possibility is to evenly distribute the data bearingmembers across the two data centers and store the remaining member(either a data bearing member or an arbiter to ensure odd numberof members) in the cloud if your company policy allows.

Number of Shards

Sharding requires at least two shards to distribute sharded data. Singleshard sharded clusters may be useful if you plan on enabling sharding inthe near future, but do not need to at the time of deployment.

Number of mongos and Distribution

Deploying multiple mongos routers supports highavailability and scalability. A common pattern is to place amongos on each application server. Deploying onemongos router on each application server reduces networklatency between the application and the router.

Alternatively, you can place a mongos router on dedicatedhosts. Large deployments benefit from this approach because it decouplesthe number of client application servers from the number ofmongos instances. This gives greater control over the numberof connections the mongod instances serve.

Installing mongos instances on their own hosts allows theseinstances to use greater amounts of memory. Memory would not be sharedwith a mongod instance. It is possible to use primary shardsto host mongos routers but be aware that memory contention maybecome an issue on large deployments.

There is no limit to the number of mongos routers you canhave in a deployment. However, as mongos routerscommunicate frequently with your config servers, monitor config serverperformance closely as you increase the number of routers. If you seeperformance degradation, it may be beneficial to cap the number ofmongos routers in your deployment.

Diagram of a sample sharded cluster for production purposes. Contains exactly 3 config servers, 2 or more ``mongos`` query routers, and at least 2 shards. The shards are replica sets.

Development Configuration

For testing and development, you can deploy a sharded cluster with aminimum number of components. These non-production clusters have thefollowing components:

Diagram of a sample sharded cluster for testing/development purposes only. Contains only 1 config server, 1 ``mongos`` router, and at least 1 shard. The shard can be either a replica set or a standalone ``mongod`` instance.

Warning

Use the test cluster architecture for testing anddevelopment only.

See also

Deploy a Sharded Cluster