如果数据量已经突破了单台服务器的处理能力。可以考虑使用分片。

分片的概念类似于数据库的分区表。不同的是数据库的分区表只是将一个segment分为多个segment存储,而MongoDB的分片，则是将每一个Segment划分到一个单独的服务器处理。和传统的数据库一样，分片需要依据一个索引列，而这个索引列一定要应用在查询中，否则不能应用分区消除的特性,这样会在每一个分区中进行查询。

MongoDB分片的组件有mongos路由服务器，配置服务器和分片服务器。而分片服务器一般作为逻辑服务器存在，实际应用中，它应该是一个副本集集群。

实验使用三台虚拟机，搭建一个具有三个分片的高可用集群。

每个虚拟机启动5个MongoDB实例。相关目录和配置文件如下：

每台虚拟机端口分配如下:

然后启动三个副本集,

最后登录mongos服务器，增加分片服务器。

查看集群分片状态。

但是,MongoDB默认不会对数据进行分片，他会将数据存储在一个分片中。除非指定了分片的数据库和集合。

可以看到MSG数据库存放在了分片2的副本集上。

设定需要分片的数据库。

设置需要分片的集合和键。如果该键没有索引，则报错如下：

在分片的键上创建索引

增加索引之后，设置分片成功

分片的键选择非常重要，一旦分片，结构就固定了。

如果后续发现用这个键不合适，就会非常非常的麻烦。

下图是采用rcvrID作为键的分片情况。
具体使用哪个键作为分片的依据，确实需要在业务层次想清楚。
和数据库分区表一样，如果业务没有考虑清楚，就创建了分区表。
导致每次查询都不能应用分区消除，结果就是全分区扫描,性能没有提升，反而下降。

Mongos路由服务器故障，应该是最好解决的一种故障。因为配置信息存放在配置服务器，数据存放在分片服务器，所以只需要重新启动mongodb实例连接配置服务器即可。

而前端JAVA程序中记录着所有mongos的信息，他发现mongos不能连接，会自动寻找pings最先返回的mongos进行连接。所以对于JAVA应用，mongos故障是透明的。

分片服务器故障处理:

由于分片由副本集组成，所以故障处理同副本集的成员故障处理。

配置服务器存放着集群的分片信息。一旦所有的配置服务器都故障，则集群基本上就彻底挂了。所以配置服务器一定要保证有3个实例分布在不同的机器(机房)上。

在任何一个配置服务器失效的时候，Mongodb集群的元数据都会变成为只读了。集群系统继续运行，但是chunks在一个分片中将会成为不可以被拆分或者是不可以跨分片进行迁移。对于大多数使用场景，这个不会导致问题，应为改变Chunk元数据进行的并不频繁。

另外，使宕机的Config Server在一个合理的时间周期（一天）内恢复是相当重要的，这样可以避免分片由于缺乏迁移而变得负载不均衡

恢复宕机的配置服务器，可以找到一个新的服务器，使用相同的IP或者主机名称。停止另外一个可用的配置服务器（或者上锁拷贝文件），将他所有的文件同步到新的服务器上。然后启动这个新的配置服务器。