Mongodb集群部署

数据副本

MongoDB中的一组副本是一群mongod进程，这些进程维护一样的数据集。副本集提供了冗余和高可用性，是生产环境部署的基础。

数据冗余和可用性

经过在不一样的服务器上存储相同的数据，副本机制保证了必定程度的容错，即在一个数据库挂掉后，数据服务仍然可用。

在某些状况下，副本能够提高数据的读性能，由于用户能够从不一样的数据库读取数据。在不一样的数据中心维护数据的拷贝，可以提升分布式应用程序的可用性。也能够维护额外的副本用于其余的目的，好比灾难恢复，告警或者是备份。

Mongo中的副本

一个Mongo副本集包括几个数据轴承节点和一个可选的仲裁者。在这些节点中，有且只有一个主节点，其余的节点都被认为是辅助节点。

主节点接收全部的写操做。一套副本中，只有主节点可以确认{ w: "majority"}；虽然在一些状况下，另外的mongod进程会在短期内认为本身是主节点。主节点将全部数据的变更记录在日志中，好比oplog

.

从节点复制主节点的oplog，而后根据日志重放数据集的变更，经过这样的方式达到和主节点的数据一致。若是主节点挂掉，一个合格的从节点将发起一次选举将本身选举为新的主节点。

能够在副本集中添加一个额外的mongod实例做为仲裁者。仲裁者不维护数据集，它的主要功能是维护节点间的心跳和响应其余副本集成员的请求。由于仲裁者不维护数据，所以和一个完整节点相比，占用的资源会更少。若是副本集中节点数量是偶数，添加一个仲裁者能够在主节点的选举中添加多数选票的能力。

仲裁者的角色不会变，主节点有可能会降级成从节点，从节点也可能升级为主节点。

异步复制

从节点异步从主节点应用操做。在从主节点同步数据后，即便有部分节点挂掉，副本集依然能够保持工做。

自动故障转移

当一个主节点和副本集中的其余节点有超过10秒中的链接断开时，一个合格的从节点将发起选举，将本身提高为主节点。第一个发起选举而且获得副本集中大多数选票的节点会成为主节点。

故障转移过程一般在一分钟内完成。副本集中的其余节点可能须要10到30秒来让确认主节点不可访问。在确认后将发起选举。选举的过程可能须要10到30秒。

读操做

默认状况下，用户会从主节点中读取数据，不过用户也能够经过设置发送读请求到从节点。异步制意味着从节点中的数据可能和主节点并不一致。

数据分片

数据分片是将数据分散存储在多个机器上。MongoDB使用分片技术来支持部署很是大的数据集，并提升系统的吞吐量。

单服务器会面临大量数据和高吞吐量的应用程序的挑战。好比，高频率的查询会耗尽服务器的CPU资源；大于系统内存的工做数据集会对磁盘的I/O形成很大压力。

有两种方式来应对系统数据的增加：垂直扩展和水平扩展。

垂直扩展包括增长单个服务器的能力，好比使用更强的CPU，添加更多内存，或者增长存储空间。现有技术的局限可能让单台机器没法应对某个给定的工做负载。另外，云服务商可以提供的硬件配置也有必定的上限。所以在实践中，垂直扩展可以应对的负载有上限。

水平扩展包括数据集的划分，和多台服务器分摊负载，水平扩展能够经过添加新的机器来提高处理能力。虽然单机的能力可能不是很强，可是每台机器都负责处理总体负载的一个子集，所以有能力提供比高速大容量服务器更高的效率。水平扩展提高系统的处理能力只须要添加新的服务器，这比提高高端服务器性能所需的成本要低。缺点是增长了基础设施部署和维护的复杂度。

MongoDB经过分片技术支持系统的水平扩展。

分片集群

MongoDB的分片集群中有如下组件：

• shard：每一个shard都包含数据分片的一个子集。每一个shard均可以部署为一个副本集
• mongos：mongos做为查询路由，提供客户端应用程序和分片集群之间的接口
• config servers：config servers存储集群中的元数据和配置数据。在Mongo3.4中，config server必须被部署为副本集。

下图展现了各个组件之间的交互。

Shard Keys

MongoDB使用shard key对collection的数据分片。shard key由一个不可变的字段或目标collection中每一个文档都存在的字段组成。

须要在对collection分片的时候选择shard key。shard key以后不能更改。一个分片的collection只能有一个shard key。

要对一个非空collection分片，collection必须有一个由shard key开始的索引。对于空的collection，若是没有一个合适索引，MongoDB会建立索引。

shard key的选择会影响集群的性能，效率和可扩展性。shard key可能会成为集群的瓶颈，即便集群中的机器性能都很高。

chunks

MongoDB将数据分片到chunk中。依据选择的shard key，每一个chunk大小都有下限和上限。

在集群中，MongoDB使用分片集群均衡器迁移各个chunk。均衡器试图实如今集群中chunk的均衡。

分片的优势

读/写

MongoDB在分片集群中，将读和写的负载分配到各个节点中，容许每一个shard处理集群操做的一个子集。能够经过添加更多的shard横向扩展这种读写能力。

对于包括shard key的查询，mongos能够将查询定位到特定的shard。

存储性能

分片技术将数据分配到集群中的节点上，每一个shard包含总数据集合的一个子集。随着数据集的增加，添加shard可以增长集群的存储容量。

高可用

即便在部分shard不可用的状况下，集群依然能够继续执行部分读／写操做。在挂掉的shard不可用期间，可用的shard的读写不受影响。

在生产环境中，shard应该部署为副本集，以提供数据冗余和可用性。

分片注意事项

在集群上实施分片须要仔细地规划，执行和维护。

仔细选择shard key，对于确保集群的性能和效率是必要的。在分片后不能改变shard key，也不能撤销分片。

分片有必定的操做要求和限制。

若是查询不包括shard key，mongos会广播操做，在集群中的shard中执行查询。这样的查询可能有较长耗时。

分片和非分片collection

一个数据库可能同时有分片的collection和非分片的collection。分片的collection是分区的，分布在集群的不一样shard中。非分片的collection存储在主shard中。每一个数据库都有本身的主shard。

分片集群的链接

必须链接到mongos路由，来与分片集群中的collection交互。这种交互包括分片collection和非分片collection。客户端不容许直接链接到单独的shard来进行读写操做。

分片策略

MongoDB支持两种分片策略。

哈希分片

哈希分片是对shard key的值进行哈希运算后进行分片。每一个chunk基于哈希后的值进行分配。

一个范围内的shard key可能很接近，可是hash后的结果极可能不在同一个chunk中。基于哈希的数据分布会造成更加均衡的数据分布，特别是在shard key单调变化的状况下。

可是，哈希分布意味着对范围查询不太可能定位到单个shard，这会致使广播操做。

范围分片

范围分片是将数据基于shard key的值进行切分。每一个chunk基于shard key的值进行分配。

shard key某个范围内的值更可能分配在相同的chunk中，mongos会将请求导向只含有请求数据的shard中。

范围分片的效率取决于shard key。欠考虑的shard key会致使数据的分布不均，这会减小数据分片的优点或者致使性能瓶颈。

分片集群的区域

在分片集群中，能够基于shard key建立数据区域。能够把集群中的多个shard在同个区域中关联起来。一个shard能够和任意数量的非冲突区域关联起来。在平衡的集群中，MongoDB会将区域中的chunk迁移到区域里关联的shard中。

每一个区域包括一个或多个范围的shard key。每一个区域的覆盖范围老是包容它的下边界和排它的上界。