Shards
A shard contains a subset of sharded data for a shardedcluster. Together, the cluster’s shards hold the entire data set for thecluster.
As of MongoDB 3.6, shards must be deployed as a replica set toprovide redundancy and high availability.
Users, clients, or applications should only directly connect to a shard toperform local administrative and maintenance operations.
Performing queries on a single shard only returns a subset of data. Connect tothe mongos
to perform cluster level operations, including read orwrite operations.
Important
MongoDB does not guarantee that any two contiguous chunksreside on a single shard.
Primary Shard
Each database in a sharded cluster has a primary shard that holds allthe un-sharded collections for that database. Each database has its ownprimary shard. The primary shard has no relation to the primary in areplica set.
The mongos
selects the primary shard when creating a new databaseby picking the shard in the cluster that has the least amount of data.mongos
uses the totalSize
field returned by thelistDatabase
command as a part of the selection criteria.
To change the primary shard for a database, use the movePrimary
command. The process of migrating the primary shard may take significant timeto complete, and you should not access the collections associated to thedatabase until it completes. Depending on the amount of data being migrated,the migration may affect overall cluster operations. Consider the impact tocluster operations and network load before attempting to change the primaryshard.
When you deploy a new sharded cluster with shards that werepreviously used as replica sets, all existing databasescontinue to reside on their original replica sets. Databases createdsubsequently may reside on any shard in the cluster.
Shard Status
Use the sh.status()
method in the mongo
shell tosee an overview of the cluster. This reports includes which shard isprimary for the database and the chunk distribution across theshards. See sh.status()
method for more details.
Sharded Cluster Security
Use Internal/Membership Authentication to enforce intra-clustersecurity and prevent unauthorized cluster components from accessing thecluster. You must start each mongod
in the cluster with theappropriate security settings in order to enforce internal authentication.
See Deploy Sharded Cluster with Keyfile Authentication for atutorial on deploying a secured sharded cluster.
Shard Local Users
Each shard supports Role-Based Access Control(RBAC) for restrictingunauthorized access to shard data and operations. Start each mongod
in the replica set with the —auth
option to enforce RBAC.Alternatively, enforcing Internal/Membership Authentication forintra-cluster security also enables user access controls via RBAC.
Each shard has its own shard-local users. These users cannot be usedon other shards, nor can they be used for connecting to the clustervia a mongos
.
See Enable Access Control for a tutorial on enablingadding users to an RBAC-enabled MongoDB deployment.