【Mongodb】 Replica set 的选举策略之一

首先介绍一下在replica set里分为三种节点类型：

1<b> primary </b>  负责client的读写。

2 <b>secondary</b> 作为热备节点，应用Primary的oplog读取的操作日志,和primary保持一致，不提供读写操作！

  secondary有两种类型: 

  1)normal secondary   随时和Primay保持同步,  

  2)delayed secondary  延时指定时间和primary保持同步,防止误操作. 

3 <b>arbiter</b>.它不负责任何读写,只作为一个仲裁者，负责primary down的时候剩余节点的选举操作.

    在Replica Set 如果主库down了，要进行故障切换，集群的选举策略：

当primary当了之后，剩下的节点会选择一个primary节点，仲裁节点也会参与投票，避免僵局出现(如果没有仲裁节点，对于两节点的replica set 从节点down，主节点会变为secondary，导致整个replica set 不可用)选择依据为：优先级最高的且数据新鲜度最新的！

    primary 节点使用心跳来跟踪集群中有多少节点对其可见。如果达不到1/2，活跃节点会自动降级为secondary。这样就能够防止上面说的僵局状态或者当网络切割后primary已经与集群隔离的时候！

<b>来自官方文档的例子：</b>

<b>初始状况：</b>

server-a: secondary oplog: ()

server-b: secondary oplog: ()

server-c: secondary oplog: ()

<b>主库写入数据</b>

server-a: primary oplog: (a1,a2,a3,a4,a5)

<b>secondary库应用数据</b>

server-b: secondary oplog: (a1)

server-c: secondary oplog: (a1,a2,a3)

…

<b>主库</b><b>server-a</b><b>down</b>

...

server-c: primary oplog: (a1,a2,a3) // c 具有最新的数据被选择为primary库

server-b: secondary oplog: (a1,a2,a3)

server-c: primary oplog: (a1,a2,a3,c4)

<b>server-a 恢复或者起来</b>

server-a: recovering oplog: (a1,a2,a3,a4,a5) --做数据恢复

<b>…应用从server-c中的数据，此时 数据a4，a5丢失</b>

server-a: recovering oplog: (a1,a2,a3,c4)

server-b: secondary oplog: (a1,a2,a3,c4)

<b>新的主库server-c进行数据写入。</b>

server-a: secondary oplog: (a1,a2,a3,c4)

server-c: primary oplog: (a1,a2,a3,c4,c5,c6,c7,c8)

server-a: secondary oplog: (a1,a2,a3,c4,c5,c6,c7,c8)

server-b: secondary oplog: (a1,a2,a3,c4,c5,c6,c7,c8)

从上面的过程中可以看出server-c 变为主库，其他节点则应用从server-c的日志。数据a4，a5 丢失。

    当选出新的primary之后，此数据库的数据就会被假定为整个集群中的最新数据，对其他节点(原来的活跃节点)的操作都会回滚，即便之前的主库已经恢复工作了。为了完成回滚，所有节点连接新的主库后都要重新进行同步。此过程如下：

<b>这些节点会查看自己的oplog日志，找到还没应用的主库操作，然后向主库请求这些操作影响的文档的最新副本，进行数据同步。</b>