、

参考

MongoDB副本集
MongoDB的副本集
MongoDB 教程

一、副本集概念

MongoDB复制是将数据同步在多个服务器的过程。

复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。
通俗的讲就是用多台机器进行同一数据的异步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。

1、主要功能

• （1）数据冗余：副本集可以确保副本节点与主节点数据的更新，以防止单个数据库的服务宕机造成数据丢失的问题。这些副本节点可以和主节点位于同一个数据中心或处于安全考虑分布于其他数据中心

• （2）自动故障转移：副本集没有固定的主节点，整个集群会选举出一个主节点，当这个主节点不会正常工作时，会选举一个副本节点切换为主节点，客户端会连接到这个新的主节点，并且数据和应用程序都将保持可用。MongoDB副本集实现这样的主/副本切换是自动的，因此副本集是保证MongoDB高可用的基础。

• （3）读写分离：副本集可以将读取请求分流到所有副本集上，以减轻主节点的读写压力。

2、主从复制和副本集区别

主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多个备份节点(从、secondary)。

3、复制结构图

mongodb的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。

mongodb各个节点常见的搭配方式为：一主一从、一主多从。

主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。

MongoDB复制结构图如下所示：

从以上结构图可知，客户端从主节点读取数据，在客户端写入数据到主节点时， 主节点与从节点进行数据交互保障数据的一致性。

二、副本集成员角色

1.主节点

主节点是副本集中负责处理客户端请求和读写数据的主要成员。主节点通过iplog(操作日志)记录所有操作。副本集中有且只有一个主节点，如果当主节点不可用时，则会从副本节点中选举出新的主节点。

2.副本节点

副本节点定期轮询主节点来获取oplog记录的操作内容，然后对自己的数据副本执行这些操作，从而保证副本节点的数据副本与主节点保持一致。副本集中可以有一个或者多个副本节点。当主节点宕机时，副本集会根据副本节点的优先级进行选举，确定哪个副本节点成为新的主节点。

3.仲裁节点

仲裁节点不会同步主节点的数据副本，也不会被选举为主节点，它主要时参与选举投票。由于仲裁节点没有访问压力，比较空闲，因此仲裁节点需要的资源很小。
当然也可以将仲裁服务器维护为副本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。

您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。

• 如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。
  仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要
  人员。
• 如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。
• 如果你的副本+主节点的个数是奇数，可以不加仲裁者。

三、副本集架构（一主一副本一仲裁）

默认情况下，从节点只是一个备份，是没有读写权限的，可以增加读的权限，但需要进行设置。

1、设置读操作权限：

说明：设置为奴隶节点，允许在从成员上运行读的操作

语法：rs.slaveOk() 或rs.slaveOk(true)

提示：
该命令是 db.getMongo().setSlaveOk() 的简化命令。
现在可实现了读写分离，让主插入数据，让从来读取数据。

2、取消作为奴隶节点的读权限

rs.slaveOk(false)

四、选举原则

1、触发条件

MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件：

• 1） 主节点故障
• 2） 主节点网络不可达（默认心跳信息为10秒）
• 3） 人工干预（rs.stepDown(600)）

2、选举规则

选举规则是根据票数来决定谁获胜：票数最高，且获得了“大多数”成员的投票支持的节点获胜。
“大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。即半数以上。

例如：3个投票成员，则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。
若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。

数据的新旧是通过操作日志oplog来对比的。
在获得票数的时候，优先级（priority）参数影响重大。
可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加
0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员
更有资格成为主要成员，更低的值可使成员更不符合条件。
默认情况下，优先级的值是1
可以看出，主节点和副本节点的优先级各为1，即，默认可以认为都已经有了一票。但选举节点，优先
级是0，（要注意是，官方说了，选举节点的优先级必须是0，不能是别的值。即不具备选举权，但具有
投票权）

五、故障测试

1、副本节点故障测试

关闭27018副本节点：
发现，主节点和仲裁节点对27018的心跳失败。因为主节点还在，因此，没有触发投票选举。
如果此时，在主节点写入数据。

2、主节点故障测试

发现，从节点和仲裁节点对27017的心跳失败，当失败超过10秒，此时因为没有主节点了，会自动发起
投票。
而副本节点只有27018，因此，候选人只有一个就是27018，开始投票。
27019向27018投了一票，27018本身自带一票，因此共两票，超过了“大多数”
27019是仲裁节点，没有选举权，27018不向其投票，其票数是0.
最终结果，27018成为主节点。具备读写功能。
再启动27017节点，发现27017变成了从节点，27018仍保持主节点。
登录27017节点，发现是从节点了，数据自动从27018同步。
从而实现了高可用。

3、仲裁节点和主节点故障

先关掉仲裁节点27019，
关掉现在的主节点27018
登录27017后，发现，27017仍然是从节点，副本集中没有主节点了，导致此时，副本集是只读状态，
无法写入。
为啥不选举了？因为27017的票数，没有获得大多数，即没有大于等于2，它只有默认的一票（优先级
是1）
如果要触发选举，随便加入一个成员即可。
如果只加入27019仲裁节点成员，则主节点一定是27017，因为没得选了，仲裁节点不参与选举，
但参与投票。（不演示）
如果只加入27018节点，会发起选举。因为27017和27018都是两票，则按照谁数据新，谁当主节
点。

4、仲裁节点和从节点故障

先关掉仲裁节点27019，
关掉现在的副本节点27018
10秒后，27017主节点自动降级为副本节点。（服务降级）
副本集不可写数据了，已经故障了。

三节点的副本集，任何一台故障，集群都会进行自动的切换，不影响的服务
三节点的副本集，故障任何两个节点，集群会变的不可用，需要手动处理

六、部署副本集

参考：https://blog.csdn.net/m0_57979544/article/details/124640287

开展副本集之前首先规划各服务器的基本信息以及角色分配

服务器基本信息及角色分配

虚拟机名称	IP地址	成员角色	主机名(hostname)
nosql01	192.168.47.130	主结点	nosql01
nosql02	192.168.47.131	副本结点	nosql02
nosql03	192.168.47.133	副本结点	nosql03