搭建高可用mongodb集群（三）—— 深入副本集内部机制
在上一篇文章《搭建高可用mongodb集群（二）—— 副本集》 介绍了副本集的配置，这篇文章深入研究一下副本集的内部机制。还是带着副本集的问题来看吧！ 副本集故障转移，主节点是如何选举的？能否手动干涉下架某一台主节点。 官方说副本集数量最好是奇数，为什么？ mongodb副本集是如何同步的？如果同步不及时会出现什么情况？会不会出现不一致性？ mongodb的故障转移会不会无故自动发生？什么条件会触发？频繁触发可能会带来系统负载加重？ Bully算法 mongodb副本集故障转移功能得益于它的选举机制。选举机制采用了Bully算法，可以很方便从分布式节点中选出主节点。一个分布式集群架构中一般都有一个所谓的主节点，可以有很多用途，比如缓存机器节点元数据，作为集群的访问入口等等。主节点有就有吧，我们干嘛要什么Bully算法？要明白这个我们先看看这两种架构： 指定主节点的架构，这种架构一般都会申明一个节点为主节点，其他节点都是从节点，如我们常用的mysql就是这样。但是这样架构我们在第一节说了整个集群如果主节点挂掉了就得手工操作，上架一个新的主节点或者从从节点恢复数据，不太灵活。 mongodb4 不指定主节点，集群中的任意节点都可以成为主节点。mongodb也就是采用这种架构，一但主节点挂了其他从节点自动接替变成主节点。如下图： mongodb故障转移 好了，问题就在这个地方