MongoDB的1.6版本中auto-sharding功能基本稳定并可以尝试放到生产环境下使用。因为其是auto-sharding，即 mongodb通过mongos(一个自动分片模块，用于构建一个大规模的可扩展的数据库集群,这个集群可以并入动态增加的机器)自动建立一个水平扩展的 数据库集群系统，将数据库分表存储在sharding的各个节点上。

　　一个mongodb集群包括一些shards(包括一些mongod进程)，mongos路由进程，一个或多个config服务器

　　(注：本文的测试用例需求64位的mongo程序,因为我在32位的mongo没成功过)。

　　下面是一些相关词汇说明:

　　Shards : 每一个shard包括一个或多个服务和存储数据的mongod进程(mongod是MongoDB数据的核心进程)典型的每个shard开启多个服务来提高服务的可用性。这些服务/mongod进程在shard中组成一个复制集

　　Chunks: Chunk是一个来自特殊集合中的一个数据范围，(collection，minKey，maxKey)描叙一个chunk，它介于minKey和 maxKey范围之间。例如chunks 的maxsize大小是100M，如果一个文件达到或超过这个范围时，会被切分到2个新的chunks中。当一个shard的数据过量时，chunks将 会被迁移到其他的shards上。同样，chunks也可以迁移到其他的shards上

　　Config Servers : Config服务器存储着集群的metadata信息，包括每个服务器，每个shard的基本信息和chunk信息Config服务器主要存储的是chunk信息。每一个config服务器都复制了完整的chunk信息。

　　接着看一下要配置的测试环境信息：

　　模拟2个shard服务和一个config服务, 均运行在10.0.4.85机器上，只是端口不同：

　　Shard1：27020

　　Shard2：27021

　　Config：27022

　　Mongos启动时默认使用的27017端口

　　在C,D,E磁盘下分别建立如下文件夹：

　　mongodb\bin

　　mongodb\db

　　然后用CMD命令行依次打开相应文件夹下的mongd文件:

         (注:config配置服务器)

　　启动mongos时，默认开启了27017端口：

　　然后打开mongo:

　　E:\mongodb\bin>mongo 回车 (有时加端口会造成下面的addshard命令出问题)

　　注：如果要移除sharding，可用下面写法

　　db.runCommand( { removeshard : "localhost:10000" } );

　　> db.runCommand({listshards:1}); 查看shard节点列表

　 　通过上面的结果，可以出现16万条记录均分在了两个sharding上，其中shard0000中有62434条，shard0001中有99097 条。下面看一下这两个sharding-chunk的分布情况(图中的错误提示‘输入字符串格式不正确’主要因为运行环境与编译程序使用的环境不同，一个 是64，一个是32位系统)：

　 　可以看到数据被按区间自动分割开了，有点像sqlserver的数据分区表，只不过这是自动完成的(目前我没找到可以手工指定区间上下限的方式，如有知 道的TX可以跟我说一下)。当然在本文中的测试中，共有5个chunk,其中4个位于shard0001，这种情况可以在每次测试过程中会发生变化，包括 两个sharding被分配的记录数。另外就是在mongodb移动过程前后会在shard0000上生成一个文件夹，里面包括一些bson文件，名字形 如(表格+日期等信息)：

　　post-cleanup.2010-09-07T04-13-31.1.bson

　　该文件主要包括一些数据库，表结构及相关记录等信息，我想应该是用于数据恢复备份的。