# 副本集模式原理
# 1. 副本集的原理
副本集的原理与主从很相似，唯一不同的是，在主节点出现故障的时候，主从配置的从服务器不会自动的变为主服务器，而是要通过手动修改配置。但是副表集就不用，它会自动选出一台服务器做为主节点，从而保障系统的稳定性。
# 2. 副本集新的主节点是怎么选举出来的呢
是通过bully算法来的，也就是一致性协议。具体如下
- 当主节点挂了后,副本集会获得其他从节点的最后更新时间与主服务做对比。
- 如果所有从节点的最后更新时间都是很旧,那就选举停止。
- 如果副本集中的大部分服务器挂了,包含主节点,那么选举也停止。
- 如果以上情况都没有发生,那就更新时间最新的被选举为主节点。
- 如果更新时间都一样,那么谁最快成为主节点就谁做为主节点。
注意：参数选举的节点必须是副本集中的半数节点以上，如果已经小于一半了所有节点保持只读状态。
日志将会出现：can't see a majority of the set, relinquishing primary
当然还有其他方法可以干预自然选举主节点的：
- 设置从节点的优先级：通过priority，优先级高的先成为主节点。
- 强制下架主节点：db.adminCommand({replSetStepDown:1,force:true})。
# 3. 什么情况下会触发选举这个行为呢:
- 配置副本集环境，做副本集初始化的时候。
- 当主节点挂掉的时候。
- 当主节点与其他节点无法通信的时候，即网络出现问题的时候。
# 4. 副本集中的节点的角色
- primary：主节点。
- arbiteronly：仲裁节点，不存储数据，只参与选举。
- Secondary-Only：不能成为主节点，只能做为从节点，并可以参与选举。
- Hidden：隐藏不被链接的从节点，不被程序访问，但可以参与选举的节点。
- Delayed：可以指定一个时间延迟从primary节点同步数据。主要用于备份数据，如果实时同步，误删除数据马上同步到从节点，恢复又恢复不了。
- Non_voting：没有得参与选举，只负责备分数据。
设置方法：在初始化的时候把相关的角色设置为true就行了。
# 5. 副本集的节点总数为什么要为奇数
假设你有一个副本集，这个副本集有四台服务器，分别两两位于不同的机房，这时两个机房之间的通信网络出故障断了，主节点与另一个机房的节点不能通信，这时候就会触发重新选举主节点的行为。但两个机房的服务器都是两台，占用这个副本集的服务器数量都没有达到半数以上，这个时候选举停止，副本集失效。假如是5台分布在两个机房那就有一个机房是三台服务器，超过副本集的一半，产生选举。
# 6. 配置副本集的流程:
- 创建副本集的目录与副本集日志目录
- 以副本集启动mongodb
- 初始化副本集