带着副本集的问题来看吧！
- 副本集故障转移，主节点是如何选举的？能否手动干涉下架某一台主节点。
- 官方说副本集数量最好是奇数，为什么？
- mongodb副本集是如何同步的？如果同步不及时会出现什么情况？会不会出现不一致性？
- mongodb的故障转移会不会无故自动发生？什么条件会触发？频繁触发可能会带来系统负载加重？
Bully算法
mongodb副本集故障转移功能得益于它的选举机制。选举机制采用了Bully算法，可以很方便从分布式节点中选出主节点。一个分布式集群架构中一般都有一个所谓的主节点，可以有很多用途，比如缓存机器节点元数据，作为集群的访问入口等等。主节点有就有吧，我们干嘛要什么Bully算法？要明白这个我们先看看这两种架构：
- 指定主节点的架构，这种架构一般都会申明一个节点为主节点，其他节点都是从节点，如我们常用的mysql就是这样。但是这样架构我们在第一节说了整个集群如果主节点挂掉了就得手工操作，上架一个新的主节点或者从从节点恢复数据，不太灵活。
- 不指定主节点，集群中的任意节点都可以成为主节点。mongodb也就是采用这种架构，一但主节点挂了其他从节点自动接替变成主节点。
好了，问题就在这个地方，既然所有节点都是一样，一但主节点挂了，怎么选择出来下一个节点是谁来做为主节点呢？这就是Bully算法解决的问题。
那什么是Bully算法，Bully算法是一种协调者（主节点）竞选算法，主要思想是集群的每个成员都可以声明它是主节点并通知其他节点。别的节点可以选择接受这个声称或是拒绝并进入主节点竞争。被其他所有节点接受的节点才能成为主节点。节点按照一些属性来判断谁应该胜出。这个属性可以是一个静态ID，也可以是更新的度量像最近一次事务ID（最新的节点会胜出）。详情请参考NoSQL数据库分布式算法的协调者竞选还有维基百科的解释>
选举
那mongodb是怎进行选举的呢？官方这么描述:
We>
- get maxLocalOpOrdinal from each server.
- if a majority of servers are not up (from this server’s POV), remain in Secondary mode and stop.
- if the last op time seems very old, stop and await human intervention.
- else, using a consensus protocol, pick the server with the highest maxLocalOpOrdinal as the Primary.
大致翻译过来为使用一致协议选择主节点。基本步骤为：
- 得到每个服务器节点的最后操作时间戳。每个mongodb都有oplog机制会记录本机的操作，方便和主服务器进行对比数据是否同步还可以用于错误恢复。
- 如果集群中大部分服务器down机了，保留活着的节点都为 secondary状态并停止，不选举了。
- 如果集群中选举出来的主节点或者所有从节点最后一次同步时间看起来很旧了，停止选举等待人来操作。
- 如果上面都没有问题就选择最后操作时间戳最新（保证数据是最新的）的服务器节点作为主节点。
这里提到了一个一致协议（其实就是bully算法），这个和数据库的一致性协议还是有些区别，一致协议主要强调的是通过一些机制保证大家达成共识；而一致性协议强调的是操作的顺序一致性，比如同时读写一个数据会不会出现脏数据。一致协议在分布式里有一个经典的算法叫“Paxos算法”，后续再介绍。
上面有个问题，就是所有从节点的最后操作时间都是一样怎么办？就是谁先成为主节点的时间最快就选谁。
选举触发条件
选举不是什么时刻都会被触发的，有以下情况可以触发。
- 初始化一个副本集时。
- 副本集和主节点断开连接，可能是网络问题。
- 主节点挂掉。
选举还有个前提条件，参与选举的节点数量必须大于副本集总节点数量的一半，如果已经小于一半了所有节点保持只读状态。
日志将会出现：
