MongoDB副本集原理
Secondary初次同步数据时,会先进行init sync 操作,从Primary(或其它数据更新的Secondary)同步全量数据,然后不断通过tailable cursor从Primary的local.oplog.rs集合里查询最新的oplog并应用到自身。
假设复制集内投票成员的数量为N,则大多数为N/2 + 1,当复制集内存活成员数量不足大多数时,整个复制集将无法选举出Primary,复制集将无法提供写服务,处于只读状态。
之所以使用投票成员数为奇数,是由于偶数节点和奇数节点容忍失效数一致,所以奇数节点从成本和冗余角度讲更具性价比。
容忍失效数=投票成员数-大多数,即容忍失效数=N - N/2 - 1 = N/2 - 1
下表列举了投票成员节点数数、大多节点数和容忍失效节点数的关系:
投票成员数 | 大多数 | 容忍失效数 |
1 | 1 | 0 |
2 | 2 | 0 |
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
7 | 4 | 3 |
从上表中可以看出,当复制集内能够容忍的失效节点数相同时所需要的大多数节点数量越少,那么此时的投票成员数越少越好,也就是复制集内为投票成员数为奇数的性价比要高些;故,副本集架构最低建议配置是3个成员,1个Primary节点和2个Secondary节点(不建议部署仲裁节点)。
复制集成员:Primary\Secondary\Arbiter
在3.0版本之前,副本集最多可以有12个成员;在3.0版本之后,副本集可以多达50名成员,但只有7个有投票权。
Secondary节点的配置方法:
- 配置为Priority 0的节点:无法被选举为Primary节点,只能作为冷备节点
- 配置为隐藏的节点:无法让应用从这类节点读取数据
- 配置为延迟节点:用于误操作数据恢复
Arbiter节点,即不会存储数据,也不会被选举为主节点;从3.6版本起,仲裁节点的Priority默认设置为0。
阅读是一种修养,分享是一种美德。