1.步骤一: 启动Shard Server
步2.骤二: 启动Config Server
注意，这里我们完全可以像启动普通mongodb服务一样启动，不需要添加—shardsvr和configsvr参数。因为这两个参数的作用就是改变启动端口的，所以我们自行指定了端口就可以 3.步骤三: 启动Route Process ./bin/mongos --port 4000 --configdb localhost:27027 --fork --logpath /usr/local/mongodb/data/shard/log/route.log --chunkSize=1 # 启动Route Server实例 mongos启动参数中，chunkSize这一项是用来指定chunk的大小的，单位是MB，默认大小为200MB，为了方便测试Sharding效果，我们把chunkSize指定为 1MB。意思是当这个分片中插入的数据大于1M时开始进行数据转移 4.步骤四: 配置Sharding
注意这里我们要注意片键的选择，选择片键时需要根据具体业务的数据形态来选择，切不可随意选择，实际中尤其不要轻易选择自增_id作为片键，除非你很清楚你这么做的目的，具体原因我不在此分析，根据经验推荐一种较合理的片键方式，“自增字段+查询字段”，没错，片键可以是多个字段的组合。 另外这里说明一点，分片的机制：mongodb不是从单篇文档的级别,绝对平均的散落在各个片上, 而是N篇文档,形成一个块"chunk",优先放在某个片上, 当这片上的chunk,比另一个片的chunk区别比较大时(>=3) ,会把本片上的chunk,移到另一个片上, 以chunk为单位,维护片之间的数据均衡。 也就是说，一开始插入数据时，数据是只插入到其中一块分片上的，插入完毕后，mongodb内部开始在各片之间进行数据的移动，这个过程可能不是立即的，mongodb足够智能会根据当前负载决定是立即进行移动还是稍后移动。 在插入数据后，立马执行db.users.stats();两次可以验证如上所说。 这种分片机制,节省了人工维护成本,但是由于其是优先往某个片上插入,等到chunk失衡时,再移动chunk,并且随着数据的增多,shard的实例之间,有chunk来回移动的现象,这将会为服务器带来很大的IO开销,解决这种开销的方法,就是手动预先分片;
手动预先分片 以shop.user表为例：
repliction set and shard 一般mongoDB如果真的到了分片的级别后,那片服务器避无可免的要用到复制集,部署的基本思路同上,只需要注意两点: sh.addShard( host ) server:port OR setname/server:port # 如果是复制集的片服务器,我们应该复制集的名称写在前面比如 sh.addShard('ras/192.168.42.168:27017'); # 27017也就是复制集中的primary 另外在启动本机的mongod服务的时候,最好把ip也给写进去,否则有可能会有不可预知的错误。
查看分片配置的方法：
1.列举使用分片的数据库 为了列举使用分片的数据库，需要查询Config数据库。如果partitioned域值为true，则这个库使用了分片技术。 连接一个mongos实例，运行命令获取使用分片功能的数据库：
例如：使用以下命令返回集群中的所有数据库
如果返回结果：
显示只有mydb使用了分片。
2.列举所有的分片 为了列举当前集合的所有分片，使用listShards命令：
返回结果：
3.查看集群的详细信息 为了查看集群的详细信息，可以使用db.printShardingStatus()或者sh.status()。所有的方法返回同样的结果。 例如，使用
查看信息：
（1）sharding version展示了分片元数据的版本号。 （2）shards展示了在集群中被作为分片的mongod实例。 （3）databases展示了集群中所有的数据库，包括没有使用分片功能的库。 （4）chunks信息展示了mydb库的每个分片上有多少个块和每个块的范围。
