mongodb高可用方案（三）可复制集内部机制

笔记大纲

1、主从架构图和副本集架构图

2、主节点选举算法( bully算法)、触发选举条件、如何人工干预主节点。

3、副本集个数为什么是 奇数个，防止无法选举出主节点，参与选举的节点 最多只能有7个节点参与，在 未选举出主节点时则整个集群只提供只读服务， 当集群中所有的secondary节点都挂了这时主节点会自动降级为secondary节点对外提供只读服务，不提供写服务。

4、集群中所有节点必须每 2秒钟向其他节点 发送心跳包，如果其他节点 10秒没有响应则标记为不能访问，副本节点需要维护其他所有节点角色、日志时间等信息。而主节点除了以上信息还需要检查自己能否和其他大部分节点进行通信，如果不能则把自己降级为secondary只读节点。

5、同步，分为 初始化（全量）同步， 增量同步。节点初始化以及落后的数据量大于oplog设置的大小的时候都会进行全量同步。 因此oplog大小设置必须适中，防止多次出发全量同步。副本节点不一定只能从主节点复制，如果在不同的IDC，可能采用就近原则从已经同步完的一个节点来进行同步。

6、 java代码访问复制集只需要把所有节点配置加上，设置rs.slaveOk为true，读策略配置为secondary节点即可； 如果是分片集群，则完全透明，代码中只需要访问1个ip端口。配置多个也可以，一般配置1个ip端口即可访问分片集群。(开发难度不增加，但是需你理解原理以及如何搭建集群的。)

一、指定主节点和不指定主节点的不同架构图

主从架构

副本集架构

二、主节点选举

1、 Bully算法

Bully算法是一种 协调者（主节点）竞选算法 ，主要思想是集群的每个成员都可以声明它是主节点并通知其他节点。别的节点可以选择接受这个声称或是拒绝并进入主节点竞争。 被其他所有节点接受的节点才能成为主节点 。节点按照一些属性来判断谁应该胜出。这个属性可以是一个静态ID，也可以是更新的度量像最近一次事务ID（最新的节点会胜出）

2、使用 一致协议 选择主节点。基本步骤为

1）得到每个服务器节点的最后操作时间戳。每个mongodb都有oplog机制会记录本机的操作，方便和主服务器进行对比数据是否同步还可以用于错误恢复。

2）如果集群中大部分服务器down机了，保留活着的节点都为 secondary状态并停止，不选举了。

3）如果集群中选举出来的主节点或者所有从节点最后一次同步时间看起来很旧了，停止选举等待人来操作。

4）如果上面都没有问题就选择最后操作时间戳最新（保证数据是最新的）的服务器节点作为主节点。

一致协议（其实就是bully算法） ，这个和数据库的一致性协议还是有些区别， 一致协议主要强调的是通过一些机制保证大家达成共识；而一致性协议强调的是操作的顺序一致性 ，比如同时读写一个数据会不会出现脏数据。一致协议在分布式里有一个经典的算法叫“Paxos算法”。

3、选举触发条件

选举还有个前提条件，参与选举的节点数量必须大于副本集总节点数量的一半，如果已经小于一半了所有节点保持只读状态，不进行选举。

1）初始化一个副本集时。

2）副本集和主节点断开连接，可能是网络问题。

3）主节点挂掉。

4、主节点挂掉后如何人工干预

1）登录主节点使用下架主节点

db.adminCommand({replSetStepDown : 1})

如果杀不掉可以使用强制开关

db.adminCommand({replSetStepDown : 1, force : true})

2）设置一个从节点有比主节点有更高的优先级。

rs.conf();

cfg.members[1].priority = 2

rs.reconfig(cfg)

5、如何将Secondary节点不能设置为主节点

将这个节点的优先级设置为0。那么这个secondary节点就不能被选举为主节点。

6、一个可复制集参与选举节点有上限？

一个可复制集中 最多只能有7个节点参与选举 。如果参与选举节点过多会增加选举难度和效率。

三、副本集成员数量设置（奇数）

官方推荐副本集的成员数量为 奇数 ， 最多12个副本集节点，最多7个节点参与选举 。最多12个副本集节点是因为没必要一份数据复制那么多份，备份太多反而增加了网络负载和拖慢了集群性能；而最多7个节点参与选举是因为内部选举机制节点数量太多就会导致1分钟内还选不出主节点，凡事只要适当就好。

为什么要选用奇数个副本集?这种IDC1、IDC2各自2个节点，两个IDC之间网络不通。这种情况会导致IDC1、IDC2都只有2个节点，刚好 等于总节点数4的一半 ，这样会导致两个孤立的IDC都无法出发选举。

四、心跳

整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每两秒就会发送一次pings包，如果其他节点在10秒钟之内没有返回就标示为不能访问。 每个节点内部都会维护一个状态映射表，表明当前每个节点是什么角色、日志时间戳等关键信息 。如果是 主节点，除了维护映射表外还需要检查自己能否和集群中内大部分节点通讯，如果不能则把自己降级为secondary只读节点。

五、同步

1、同步类型

副本集同步分为 初始化同步 和 keep复制 。初始化同步指全量从主节点同步数据，如果主节点数据量比较大同步时间会比较长。而 keep复制指初始化同步过后，节点之间的实时同步一般是增量同步 。初始化同步不只是在第一次才会被触发，有以下两种情况会触发：

1）secondary第一次加入，这个是肯定的。

2）secondary落后的数据量超过了oplog的大小，这样也会被全量复制。

2、oplog的大小和全量同步的关系

那什么是oplog的大小？前面说过oplog保存了数据的操作记录，secondary复制oplog并把里面的操作在secondary执行一遍。但是oplog也是mongodb的一个集合，保存在local.oplog.rs里，但是这个oplog是一个capped collection也就是固定大小的集合，新数据加入超过集合的大小会覆盖。所以这里需要注意，跨IDC的复制要设置合适的oplogSize，避免在生产环境经常产生全量复制。oplogSize 可以通过–oplogSize设置大小，对于linux 和windows 64位，oplog size默认为剩余磁盘空间的5%

3、并非所有的副本集只能从主节点复制数据

同步也并非只能从主节点同步 ，假设集群中3个节点，节点1是主节点在IDC1，节点2、节点3在IDC2，初始化节点2、节点3会从节点1同步数据。 后面节点2、节点3会使用就近原则从当前IDC的副本集中进行复制，只要有一个节点从IDC1的节点1复制数据。

4、设置同步还要注意以下几点：

1)secondary不会从delayed和hidden成员上复制数据。

2)如果同步操作30秒都没有反应，则会重新选择一个节点进行同步。

3)只要是需要同步，两个节点的buildindexes必须要相同无论是否是true和false。buildindexes主要用来设置是否这个节点的数据用于查询，默认为true。