MongoDB Documentation, Release 3.0.4 11.5.10 How does MongoDB ensure unique _id field values when using a shard key other than _id ? 11.5.11 I’ve enabled sharding and added a second shard, but all the data is still on one server. Why? If you do not use _id as the shard key, then your application/client layer must be responsible for keeping the _id field unique. It is problematic for collections to have duplicate _id values. If you’re not sharding your collection by the _id field, then you should be sure to store a globally unique identifier in that field. The default BSON ObjectId (page 176) works well in this case. First, ensure that you’ve declared a shard key for your collection. Until you have configured the shard key, MongoDB will not create chunks , and sharding will not occur. Next, keep in mind that the default chunk size is 64 MB. As a result, in most situations, the collection needs to have at least 64 MB of data before a migration will occur. Additionally, the system which balances chunks among the servers attempts to avoid superfluous migrations. Depend- ing on the number of shards, your shard key, and the amount of data, systems often require at least 10 chunks of data to trigger migrations. You can run db.printShardingStatus() to see all the chunks present in your cluster. Yes. mongod creates these files as backups during normal shard balancing operations. If some error occurs during a migration (page 685), these files may be helpful in recovering documents affected during the migration. Once the migration has completed successfully and there is no need to recover documents from these files, you may safely delete these files. Or, if you have an existing backup of the database that you can use for recovery, you may also delete these files after migration. To determine if all migrations are complete, run sh.isBalancerRunning() while connected to a mongos in- stance. Each client maintains a connection to a mongos instance. Each mongos instance maintains a pool of connections to the members of a replica set supporting the sharded cluster. Clients use connections between mongos and mongod instances one at a time. Requests are not multiplexed or pipelined. When client requests complete, the mongos returns the connection to the pool. See the System Resource Utilization (page 287) section of the UNIX ulimit Settings (page 287) document. mongos uses a set of connection pools to communicate with each shard . These pools do not shrink when the number of clients decreases. This can lead to an unused mongos with a large number of open connections. If the mongos is no longer in use, it is safe to restart the process to close existing connections. 11.5.14 Why does mongos hold connections open? 11.5.13 How does mongos use connections? 11.5.12 Is it safe to remove old files in the moveChunk directory? 765 11.5. FAQ: Sharding with MongoDB