>

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.2, config servers can be deployed as a replica set.

Production deployment
In a production cluster, ensure that data is redundant and that your systems are highly available.

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

The following restrictions apply to a replica set configuration when used for config servers:

  • Must have zero arbiters.
  • Must have no delayed members.
  • Must build indexes (i.e. no member should have buildIndexes setting set to false).

Shard
Shards should be deployed as a replica set to provide redundancy and high availability.
Performing queries on a single shard only returns a subset of data. Connect to the mongos to perform cluster level operations, including read or write operations.

IMPORTANT
MongoDB does not guarantee that any two contiguous chunks reside on a single shard.

Every database has a primary shard that holds all the un-sharded collections for a database. The primary shard has no relation to the primary in a replica set.

chech shard status
sh.status()

Config Servers
Config servers store metadata in the Config Database.
In general, you should never edit the content of the config database directly.

Mongos
MongoDB mongos instances route queries and write operations to shards in a sharded cluster. mongosprovide the only interface to a sharded cluster from the perspective of applications. Applications never connect or communicate directly with the shards.

The mongos uses the metadata to route operations from applications and clients to the mongod instances.

Note:
The most common practice is to run mongos instances on the same systems as your application servers, but you can maintain mongos instances on the shards or on other dedicated resources.

A mongos instance routes a query to a cluster by:

  • Determining the list of shards that must receive the query.
  • Establishing a cursor on all targeted shards.

The mongos then merges the data from each of the targeted shards and returns the result document.

Certain query modifiers, such as sorting, are performed on a shard such as the primary shard before mongosretrieves the results.

To detect if the MongoDB instance that your client is connected to is mongos, use the isMastercommand.
When a client connects to a mongos, isMaster returns a document with a msg field that holds the string isdbgrid.

e.g.

{
    "ismaster" : true,
    "msg" : "isdbgrid",
}



Reference
http://blog.csdn.net/irelandken/article/details/8003203
https://docs.mongodb.com/manual/core/sharded-cluster-components/