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.

Diagram of a primary shard. A primary shard contains non-sharded collections as well as chunks of documents from sharded collections. Shard A is the primary shard.

To change the primary shard for a database, use the movePrimarycommand. 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 mongodin 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.