Sharding >
Sharded Cluster Components

Sharded Cluster Components¶

On this page

A MongoDB sharded cluster consists of the following components:

shard: Each shard contains a subset of the sharded data. Each shard can be deployed as a replica set.
mongos: The mongos acts as a query router, providing an interface between client applications and the sharded cluster.
config servers: Config servers store metadata and configuration settings for the cluster. As of MongoDB 3.4, config servers must be deployed as a replica set (CSRS).

Production Configuration¶

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

Deploy Config Servers as a 3 member replica set
Deploy each Shard as a 3 member replica set
Deploy one or more mongos routers

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

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

Deploying multiple mongos routers supports high availability and scalability. A common pattern is to place a mongos on each application server. Deploying one mongos router on each application server reduces network latency between the application and the router.

Alternatively, you can place a mongos router on each shard primary. This approach also reduces network latency between the application and the router: applications use a connection string listing all the hostnames of each shard primary. The MongoDB driver then determines the network latency for each mongos and load balances randomly across the routers that fall within a set latency window. Ensure that the server hosting the shard primary and mongos router has sufficient capacity to accommodate the extra CPU and memory requirements.

There is no limit to the number of mongos routers you can have in a deployment. However, as mongos routers communicate frequently with your config servers, monitor config server performance closely as you increase the number of routers. If you see performance degradation, it may be beneficial to cap the number of mongos 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 a minimum number of components. These non-production clusters have the following components:

A replica set config server with one member.
At least one shard as a single-member replica set.
One mongos instance.

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 and development only.