MongoDB复制集架构实现

MongoDB和MySQL一样支持类似的主从复制架构，但无法实现自动故障转移，所以官方推荐使用复制集

MongoDB的复制集相当于MySQL的主从复制结合MHA，亦或是相当于redis的主从结合sentinel机制，可以自动进行故障转移，实现了数据的高可用性，异地容灾，实现灾难恢复，也无需停机维护，而且是分片式读取数据，实现了数据的读操作的负载均衡，它的最常见的角色有两个，一个是主节点primary，一个是从节点secondary，当然还有一些特殊节点arbiter仲裁，但只有投票的权利，没有被选取的资格，不能参选，也不能进行数据访问，使用arbiter可以减轻数据存储的硬件要求，使用起来也没有什么特别大的硬件资源需求，但不要和其他的数据节点部署在同一台服务器上，在日常生产中不太推荐使用arbiter这种节点类型，一般经典架构是一主两从，除此之外，还有一些其他的设置，比如说priority0，意指优先级为0，不能够被选举为primary，但是可以参与投票，而且还可以提供数据的访问，vote0意指投票为0，自身不具有投票权限，但是可以参与选举，在复制集中，成员最多50个，但是具有投票权利的最多7个，为了效率从而设置的，hidden意指隐藏，相当于一个隐藏的节点，对外部直接提供数据的服务，用户不能访问，但是它可以给用户提供其他功能的支持，比如备份，离线计算等任务，并且不会影响复制集的服务，还有delayed延迟节点，delayed节点必须是hidden节点并且其数据落后于primary一段时间（比如1小时），因delayed节点比primary节点落后一段时间，当错误或者无效的数据写入primary时，可通过delayed节点的数据来恢复到之前的时间点，通俗来讲是为了防止误操作，比如在primary上误删除了数据，在延迟节点上可以设置一个延迟时间，经过这个时间之后才把primary上的数据复制过来，这样就可以提前在delayed节点上把数据及时备份，防止误删除所产生的影响，这些节点日常生产中用的都不是特别多，最常见的还是primary和secondary

另外还有一些和读取相关的工作模式

Read preference模式

primary主节点，默认模式，读操作只在主节点，如果主节点不可用，报错或者抛出异常

primary preferred 首选主节点，大多情况下读操作在主节点，如果主节点不可用，如故障转移，读操作在从节点

secondary 从节点，读操作旨在从节点，如从节点不可用，报错或者抛出异常

secondary preferred 首选从节点，大多数情况下读操作在从节点，特殊情况，如但主节点架构，读操作在主节点

nearest 最邻近节点，读操作在最邻近的成员，可能是主节点或者从节点

primary选举实现

具有投票权的节点两两互相发送心跳

当5次心跳未收到时判断为节点失联

如果失联的是主节点，从节点会发起选举，选出新的主节点

如果失联的是从节点则不会产生新的选举

选举基于RAFT一致性算法实现，选举成功的必要条件是大多数投票节点存活

复制集中最多50个节点成员但具有投票权的节点最多7个，且为基数个投票成员

复制集架构实现

10.0.0.8（mongoDB 5.0.4）

10.0.0.18（mongoDB 5.0.4）

10.0.0.28（mongoDB 5.0.4）

扩容及缩容节点