片式群集管理

Automatic Operation and Query Routing with mongos¶

mongos uses information from config servers to route operations to the cluster as efficiently as possible. In general, operations in a sharded environment are either:

1. Targeted at a single shard or a limited group of shards based on the shard key.
2. Broadcast to all shards in the cluster that hold documents in a collection.

When possible you should design your operations to be as targeted as possible. Operations have the following targeting characteristics:

• Query operations broadcast to all shards [1] unless the mongos can determine which shard or shard stores this data.

  For queries that include the shard key, mongos can target the query at a specific shard or set of shards, if the portion of the shard key included in the query is a prefix of the shard key. For example, if the shard key is:

  { a: 1, b: 1, c: 1 }
  

  The mongos program can route queries that include the full shard key or either of the following shard key prefixes at a specific shard or set of shards:

  { a: 1 }
  { a: 1, b: 1 }
  

  Depending on the distribution of data in the cluster and the selectivity of the query, mongos may still have to contact multiple shards [2] to fulfill these queries.

• All insert() operations target to one shard.

• All single update() operations target to one shard. This includes upsert operations.

• The mongos broadcasts multi-update operations to every shard.

• The mongos broadcasts remove() operations to every shard unless the operation specifies the shard key in full.

While some operations must broadcast to all shards, you can improve performance by using as many targeted operations as possible by ensuring that your operations include the shard key.

Sharded Query Response Process¶

To route a query to a cluster, mongos uses the following process:

1. Determine the list of shards that must receive the query.

   In some cases, when the shard key or a prefix of the shard key is a part of the query, the mongos can route the query to a subset of the shards. Otherwise, the mongos must direct the query to all shards that hold documents for that collection.

   Example

   Given the following shard key:

   { zipcode: 1, u_id: 1, c_date: 1 }
   

   Depending on the distribution of chunks in the cluster, the mongos may be able to target the query at a subset of shards, if the query contains the following fields:

   { zipcode: 1 }
   { zipcode: 1, u_id: 1 }
   { zipcode: 1, u_id: 1, c_date: 1 }
   

2. Establish a cursor on all targeted shards.

   When the first batch of results returns from the cursors:

   1. For query with sorted results (i.e. using cursor.sort()) the mongos instance performs a merge sort of all queries.

   2. For a query with unsorted results, the mongos instance returns a result cursor that “round robins” results from all cursors on the shards.

      在 2.0.5 版更改: Before 2.0.5, the mongos exhausted each cursor, one by one.

Access Control Privileges in Sharded Clusters¶

In sharded clusters, MongoDB provides separate administrative privileges for the sharded cluster and for each shard. Beyond these administration privileges, privileges for sharded cluster deployments are functionally the same as any other MongoDB deployment. See, 认证 for more information.

For sharded clusters, MongoDB provides these separate administrative privileges:

• Administrative privileges for the sharded cluster. These privileges provide read-and-write access to the config servers’ ‘admin. These users can run all administrative commands. Administrative privileges also give the user read-and-write access to all the cluster’s databases.

  The credentials for administrative privileges on the cluster reside on the config servers. To receive admin access to the cluster, you must authenticate a session while connected to a mongos instance using the admin database.

• Administrative privileges for the mongod instance, or replica set, that provides each individual shard. Each shard has its own admin database that stores administrative credentials and access for that shard only. These credentials are completely distinct from the cluster-wide administrative credentials.

  As with all mongod instances, MongoDB provides two types of administrative privileges for a shard:

  • Normal administrative privileges, which provide read-and-write access to the admin database and access to all administrative commands, and which provide read-and-write accees to all other databases on that shard.
  • Read-only administrative privileges, which provide read-only access to the admin database and to all other databases on that shard.

Also, as with all mongod instances, a MongoDB sharded cluster provides the following non-administrative user privileges:

• Normal privileges, which provide read-and-write access to a specific database. Users with normal privilege can add users to the database.
• Read-only privileges, which provide read-only access to a specific database.

For more information on privileges, see 认证.

Enable Authentication in a Sharded Cluster¶

2.0 新版功能: Support for authentication with sharded clusters.

To control access to a sharded cluster, create key files and then set the keyFile option on all components of the sharded cluster, including all mongos instances, all config server mongod instances, and all shard mongod instances. The content of the key file is arbitrary but must be the same on all cluster members.

To enable authentication, do the following:

1. Generate a key file to store authentication information, as described in the 生成密钥文件 section.

2. On each component in the sharded cluster, enable authentication by doing one of the following:

   • In the configuration file, set the keyFile option to the key file’s path and then start the component, as in the following example:

     keyFile = /srv/mongodb/keyfile
     

   • When starting the component, set --keyFile option, which is an option for both mongos instances and mongod instances. Set the --keyFile to the key file’s path.

   注解

   The keyFile setting implies auth, which means in most cases you do not need to set auth explicitly.

3. Add the first administrative user and then add subsequent users. See 添加用户.

Access a Sharded Cluster with Authentication¶

To access a sharded cluster as an authenticated admin user, see 在MongoDB中的管理访问.

To access a sharded cluster as an authenticated, non-admin user, see either of the following:

• authenticate
• db.auth()

To terminate an authenticated session, see the logout command.