MongoDB复制集
Mongodb复制集由一组Mongod实例（进程）组成，包含一个Primary节点和多个Secondary节点，Mongodb Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据，以保持复制集内所有成员存储相同的数据集，提供数据的高可用。
复制集的作用
MongoDB的复制集主要是为了实现服务的高可用。
他的实现依赖于两个方面的功能：
数据写入是将数据迅速复制到另一个独立节点上 在接受写入节点发生故障时自动选举出一个新的替代节点
在实现高可用的同时，复制集实现了几个附加功能：
数据分发：将数据从一个区域复制到另一个区域，减少另一个区域的读延迟 读写分离：不同类型的压力分别在不同的节点上执行 异地容灾：在数据中心故障时候快速切换到异地
三、常见复制集结构
一个典型的复制集由三个以上具有投票权的节点组成：
一个主节点：接受写入操作和选举时投票（读写都可以） 两个（或多个）从节点：复制主节点上的新数据和选举时投票（只读） 不推荐使用Arbiter（投票节点：空节点不接受读写只作用于投票）
复制集原理与故障恢复
5.1. 节点之间数据复制（MongoDB主从复制的原理）
当一个修改操作，无论是插入、更新或者删除，到达主节点时，它对数据的操作将被记录下来（经过一些转换），这些记录称为oplog
从节点通过在主节点上打开一个tailable游标不断获取新进入主节点的oplog，并在自己的数据上回放，以此保持跟主节点的数据一致。
5.2. 故障恢复过程
具有投票权的节点之间两两互相发送心跳，当五次心跳未收到时判断节点失联；如果失联的是主节点，从节点就会发起选举，选出新的主节点；如果失联的是从节点则不会产生新的选举。
选举基于RAFT一致性算法实现，选举成功的必要条件是大多数投票节点存活。
复制集中最多可以有50个节点，但是具有投票权的节点最多有7个。
影响选举的因素：
整个集群必须有大多数节点存活 被选举为主节点的节点必须能够被多数节点建立链接，具有较新的oplog，具有较高的优先级（手动设置）
5.3. 复制集节点常用配置
在配置复制集的时候可以添加这些参数来控制节点的状态：
priority： 副本集中通过设置priority的值来决定优先权的大小，这个值的范围是0--100，值越大，优先权越高。默认的值是1。如果值是0，那么不能成为primay。
hidden： 将一个副节点配置成隐藏节点，首先要将members[n].priority 值设置成0和members[n].hidden值设置为true，隐藏节点既不能变成Primary也不能被客户端访问，但是拥有投票选举的权利。
slaveDelay： 延迟，复制n秒前的数据，保持与主节点的时间差。这样当操作失误的时候可以用来恢复数据。
v： 是否具有投票权
六、复制集注意事项
硬件：
因为正常的复制集节点都有可能成为主节点，他们的地位是一样的，因此硬件配置要一致 为了保证节点不会宕机，各节点使用的硬件必须具有独立性 软件：
复制集各节点软件版本必须一致，以避免出现不可预知的问题
一个复制集里最多只能有50个节点，具有投票权的节点最多只能有7个，【注意】并不是具有投票权的节点才能被推选为主机，所有具有成为主机条件的节点都能成为主节点
搭建
1-准备多个实例
2-搭建复制集
登录到作为主库的实例 mongo --port 28017 admin
config = {_id: 'my_repl', members: [
{_id: 0, host: '192.168.110.11:28017'},
{_id: 1, host: '192.168.110.11:28018'},
{_id: 2, host: '192.168.110.11:28019'}]
}
rs.initiate(config)
如图表示配置成功
复制集管理操作
rs.status(); //查看整体复制集状态
rs.isMaster(); // 查看当前是否是主节点
rs.conf()； //查看复制集配置信息
rs.remove("ip:port"); // 删除一个节点
rs.add("ip:port"); // 新增从节点
rs.addArb("ip:port"); // 新增仲裁节点
特殊从节点
介绍：
arbiter节点：主要负责选主过程中的投票，但是不存储任何数据，也不提供任何服务
hidden节点：隐藏节点，不参与选主，也不对外提供服务。
delay节点：延时节点，数据落后于主库一段时间，因为数据是延时的，也不应该提供服务或参与选主，所以通常会配合hidden（隐藏）
一般情况下会将delay+hidden一起配置使用
######