首先介绍一下在replica set里分为三种节点类型：
1 primary 负责client的读写。
2 secondary 作为热备节点，应用Primary的oplog读取的操作日志,和primary保持一致，不提供读写操作！
secondary有两种类型:
1)normal secondary 随时和Primay保持同步,
2)delayed secondary 延时指定时间和primary保持同步,防止误操作.
3 arbiter.它不负责任何读写,只作为一个仲裁者，负责primary down的时候剩余节点的选举操作.
在Replica Set 如果主库down了，要进行故障切换，集群的选举策略：
当primary当了之后，剩下的节点会选择一个primary节点，仲裁节点也会参与投票，避免僵局出现(如果没有仲裁节点，对于两节点的replica set 从节点down，主节点会变为secondary，导致整个replica set 不可用)选择依据为：优先级最高的且数据新鲜度最新的！
primary 节点使用心跳来跟踪集群中有多少节点对其可见。如果达不到1/2，活跃节点会自动降级为secondary。这样就能够防止上面说的僵局状态或者当网络切割后primary已经与集群隔离的时候！
来自官方文档的例子：
初始状况：
server-a: secondary oplog: ()
server-b: secondary oplog: ()
server-c: secondary oplog: ()
主库写入数据
server-a: primary oplog: (a1,a2,a3,a4,a5)
server-b: secondary oplog: ()
server-c: secondary oplog: ()
secondary库应用数据
server-a: primary oplog: (a1,a2,a3,a4,a5)
server-b: secondary oplog: (a1)
server-c: secondary oplog: (a1,a2,a3)
…
主库
server-a
down
…
server-b: secondary oplog: (a1)
server-c: secondary oplog: (a1,a2,a3)
...
server-b: secondary oplog: (a1)
server-c: primary oplog: (a1,a2,a3) // c 具有最新的数据被选择为primary库
...
server-b: secondary oplog: (a1,a2,a3)
server-c: primary oplog: (a1,a2,a3,c4)
...
server-a 恢复或者起来
...
server-a: recovering oplog: (a1,a2,a3,a4,a5) --做数据恢复
server-b: secondary oplog: (a1,a2,a3)
server-c: primary oplog: (a1,a2,a3,c4)
…应用从server-c中的数据，此时 数据a4，a5丢失
server-a: recovering oplog: (a1,a2,a3,c4)
server-b: secondary oplog: (a1,a2,a3,c4)
server-c: primary oplog: (a1,a2,a3,c4)
新的主库server-c进行数据写入。
server-a: secondary oplog: (a1,a2,a3,c4)
server-b: 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: primary oplog: (a1,a2,a3,c4,c5,c6,c7,c8)
从上面的过程中可以看出server-c 变为主库，其他节点则应用从server-c的日志。数据a4，a5 丢失。
当选出新的primary之后，此数据库的数据就会被假定为整个集群中的最新数据，对其他节点(原来的活跃节点)的操作都会回滚，即便之前的主库已经恢复工作了。为了完成回滚，所有节点连接新的主库后都要重新进行同步。此过程如下：
这些节点会查看自己的oplog日志，找到还没应用的主库操作，然后向主库请求这些操作影响的文档的最新副本，进行数据同步。
