MongoDB之副本集创建

最新推荐文章于 2025-09-25 19:37:41 发布

原创最新推荐文章于 2025-09-25 19:37:41 发布 · 2k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#mongodb #学习 #数据库

本文介绍了MongoDB副本集的搭建过程，包括复制、同步机制、安全注意事项和选举过程。在副本集的配置中，详细阐述了如何建立三个服务器的副本集，以及如何处理过时数据和心跳检测。此外，讨论了副本集成员的配置选项，如优先级和隐藏成员，强调了在设计副本集时应考虑的主要概念。最后，提到了初始化同步和持续复制的过程，以及处理数据过时和回滚的策略。

参考数据《MongoDB权威指南》

MongoDB版本 6

公司有日志追踪链方面的项目使用MongoDB作为数据库，主要功能是追踪用户操作后服务端是如何响应的（比如响应发起时间、调用的接口名、调用其他接口情况、调用的服务器等等），数据来源主要是程序运行的日志记录部分。日志记录存入MongoDB时有指定格式，例如全局主键为开头，里面存储运行时调用其他服务时的局部主键和基本信息，然后联合组装成链路数据等等。项目使用MongoDB也是看中其高性能响应（链路数据不是非常重要的数据，没有强一致性要求，重点是速度和易于备份等，总体来说比用关系型数据库好使），且日志数据只增不改（定期备份），不会有频繁修改删除操作影响MongoDB性能的问题（修改删除影响索引）。

公司使用的副本集是由三台服务器组成的，一主两从。目前工作只接触了MongoDB副本集，未涉及分片使用，但是从项目角度上将是绰绰有余了。

下面简要介绍自己如何搭建副本集的（搭建单个MongoDB流程基本一致），并且副本集大概有哪些功效。

MongoDB是一个开源、高性能、无模式的文档型数据库，当初的设计就是用于简化开发和方便扩展，是NoSQL数据库产品中的一种。是最像关系型数据库（MySQL）的非关系型数据库。

它支持的数据结构非常松散，是一种类似于JSON的格式，叫做BSON，所以它既可以存储比较复杂的数据类型，又相当的灵活。如图，项目会引入bson相关的jar包。

备注：参考网上搭建MongoDB项目时，端口号往往是27017且没有账号密码，很容易被网络攻击（博主上午搭建完，吃个饭的功夫就被黑数据，还要给比特币才能归还数据。笑死，测试库送你了呜呜呜）

一复制

1 复制简介

复制是将数据的相同副本保存在多台服务器上的一种方法，即使一台或多台服务器停止运行，使用复制功能也可以确保应用程序正常运行和数据安全。

副本集是（replica set）一组服务器，其中一个是用于处理写操作的主节点（primary），还有多个用于保存主节点的数据副本的从节点（secondary）。如果主节点崩溃了，则从节点会从中选取出一个新的主节点。

2 建立副本集

一般来说副本集的每个成员应该分配一个专门主机，但是测试环境不允许，因此创建了三个MongoDB实例。

目录层级如下，三个mongo配置类似

补充：

1）keyFile文件是在mongo文件夹下手动创建的，然后使用命令openssl rand -base64 128 > /usr/local/mongo/keyFile 生成秘钥，再将keyFile文件复制到mongo2文件夹和mongo3文件夹里（而不是分别在三个mongo文件夹下生成）。

2）keyFile的权限为600，否则会因为权限过高而无法认证

3）mongodb.conf配置文件中port分别为16906、16907、16908（因为是一个机器创建了三个mongodb因此端口号不能重复）

replSet=lyhset则是副本集名字，后面在主节点生成副本集时名字要对上

4）在mongosh登陆16906端口号机器，使用如下命令生成mongo副本集

// _id则是mongodb.conf里设置的副本集名字

cfg={ _id:"lyhset", members:[ {_id:0,host:'43.139.80.151:16906',priority:2}, {_id:1,host:'43.139.80.151:16907',priority:1}, {_id:2,host:'43.139.80.151:16908',arbiterOnly:true}] };

rs.initiate(cfg)

// 返回如下则是成功

{ ok: 1 }

// 然后可以使用rs.status()查看副本集

// rs.help则可以看其他rs辅助函数

目前不能在不停止运行的情况下将单机服务器转换为副本集，以重新启动并初始化该副本集。因此建议及时一开始只有一台服务时，将其配置为一个单成员的副本集，这样以后增加成员就容易很多。

补充：rs辅助函数

3 网络注意事项

副本集中的每个成员都必须能够连接到其他成员（包括自身）

4 安全注意事项

配置副本集时，在绑定到IP地址之前，应该启用授权控制并且指定身份验证机制。磁盘上的数据和副本集成员之间以及副本集与客户端之前的通信进行加密。

5 观察副本集

副本集搭建好只有，主节点可以自由读写，但是从节点默认不能进行读写操作，只做故障切换功能。杀死主节点后，从节点会升级为主节点，然后可以进行读写操作。

然后重启主节点，由于最开始配置时主节点的priority数值更大，因此mongo2将会从主节点退回从节点，不能进行读写操作。

如果要从节点可以进行读操作，则可以使用 rs.secondaryOk()开启可读命令。但是不能开启写操作

补充：之所以默认情况下从节点会拒绝读请求，是因为从节点可能落后于主节点（延迟）而缺少最新的写入而读取到过期数据。，

6 更改副本集操作

rs命令，具体看文档

7 如何设计副本集

1）最重要的概念：大多数（majority）

选取主节点时需要由大多数决定，主节点只有在得到大多数支持时才能继续作为主节点，写操作被复制到大多数成员时就是安全的操作。这里的大多数指副本集一半以上的成员（这里的成员数量是基于副本集配置来的，即使某些成员停止运行或不可用也不会影响大多数的概念）。

2）只能有一个主节点

8 如何进行选举

当一个从节点无法与主节点联通时，它就会联系并请求其他副本集成员将自己选举为主节点。其他成员会做几项健全性检查：例如它们能否连接到一个主节点，而这个从节点是发起选举的节点无法连接到的？这个发起选举的从节点是否有最新数据？有没有其他更高优先级的成员可以选举为主节点？等等。

副本集成员相互间每隔两秒发送一次心跳（heartbeat也就是ping）。如果某个成员在10秒内没有反馈心跳，则其他成员会将该成员标记为无法访问。然后选举算法会尽可能让具有最高优先权的从节点发起选举。就所有能连接到的成员，被选为主节点的成员必须拥有最新的复制数据。

9 成员变量配置

1）优先级 priority：表示一个成员“渴望”称为主节点的程度，取值范围为0-100，默认为1。优先级为0的成员为被动（passive）成员，永远不能成为主节点。

2）隐藏成员：客户端不会向隐藏成员发送请求，隐藏成员也不会优先作为副本集的数据源（其他复制源不可用时隐藏成员也会被使用）。只有优先级为0的成员才能被隐藏（不能隐藏主节点）

3）选举仲裁者：仲裁者不保存数据，也不会为客户端提供服务，其唯一作用就是参与选举。成员一旦以仲裁者的身份被添加到副本集中，它就永远只能是仲裁者，且无法将仲裁者重新配置为非仲裁者，反之亦然。

最多只能使用一个仲裁者。

10 创建索引

从节点可以通过配置，不与主节点创建相同的索引。

二同步

1 同步

复制是指在多台服务器上保持相同的数据副本。MongoDB实现此功能的方式是保存操作日志（oplog），其中包含了主节点执行的每一次写操作。oplog是存在于主节点local数据库中的一个固定集合。从节点通过查询此集合以获取需要复制的操作。

每个从节点都维护着自己的oplog，用来记录它从主节点复制的每个操作。这使得每个成员都可以被用作其他成员的同步源。oplog中按顺序保存着所有执行过的写操作，每个成员都维护了一份自己的oplog，它们应该和主节点的oplog完全一致（也可能会有一些延迟）

从节点从同步源中获取操作，将其应用到自己的数据集上，然后再写入oplog中。如果应用某个操作失败（只有在基础数据已损坏或数据与主节点不一致时才会发生这种情况），则从节点会停止从当前数据源复制数据。

如果一个从节点由于某种原因而停止运行，那么当它重新启动后，就会从oplog中的最后一个操作开始同步。由于这些操作是先应用到数据上然后再写入oplog，因此从节点可能会重复已经应用到其数据上的操作。但是MongoDB中oplog中的每个操作都是幂等的，无论对目标数据集应用一次还是多次，oplog操作都会产生相同的结果。

由于oplog的大小是固定的，因此它只能容纳一定数量的操作。一般来说oplog默认大小足够。但是如果一个操作会影响多个文档，那么这个操作会被分解为多个oplog条目，此时就需要调整oplog的大小。

a）一次更新多个文档

b）删除的数量与插入的数据量相同

c）大量的就地（in-place）更新

2 常见的两种同步方式

2.1 初始化同步

a）MongoDB在执行初始化同步时，会将所有数据从副本集中的一个成员复制到另一个成员中。当一个副本集成员你启动时，它会检查自身的有效状态，以确定是否可以开始从其他成员中同步数据。如果状态有效，它就会尝试从该副本集的另一个成员中复制数据的完整副本。

b）MongoBD会克隆除local数据库之外的所有数据库。mongoDB会扫描源数据库中的每个集合，并将所有数据插入目标成员上这些集合的对应副本中，在开始克隆操作之前，目标成员上的任何现有数据库都将被删除。

c）一旦所有的数据库都被克隆，mongod就会使用这些来自同步源的oplog记录来更新它的数据集以反映副本集的当前状态，并将复制过程中发生的所有变更应用到数据集上。这些变更可能包括插入、更新和删除，而此过程可能意味着mongod必须重新克隆某些被克隆程序移动并因此丢失的文档。

d）初始化同步时间一般较长，且可能破坏同步源的工作集。一般选择不太忙时进行初始化同步。

2.2 复制

从节点成员在初始化同步之后会持续复制数据。它们从同步源复制oplog，并在一个异步过程中应用这些操作。从节点可以根据需要自动更改同步源，以应对ping时间及其他成员复制状态的变化。

3 处理过时数据

如果某个从节点远远落后于同步源当前的操作，那么这个从节点就是过时的。过时的从节点无法追赶上同步源，因为同步源上的操作过于领先了，如果继续同步从节点就需要跳过一些操作。当一个从节点过期时，它将依次尝试从副本集中的每个成员进行复制，看看是否有成员拥有更长的oplog以继续进行同步，如果没有一个成员拥有足够长的oplog，那么该成员上的复制将停止，并且需要重新进行完全同步或从最近的备份中恢复。

4 心跳

所有成员每隔两秒会向副本集的其他成员发送一个心跳请求，心跳请求用于检查每个成员的状态。

常见成员状态

a）STARTUP：成员第一次启动时的状态，这时MongoDB正在尝试加载它的副本集配置，加载成功后就切换到STARTUP2

b）STARTUP2：初始同步过程会持续处于这个状态，通常只有几秒。

c）RECOVERING：此状态标名成员运行正常，但不能处理读请求。比如需要做一些检查以确保自己处于有效状态，或者该成员远远落后其他成员而无法赶上

d）ARBITER：仲裁者节点独有的特殊状态，并且其在正常运行期间应该始终处于这个状态。

e）DOWN：如果一个成员被正常启动，后来变为不可访问，就会进入这种状态。（不可访问不代表不能运行）

f）UNKNOWN：如果一个成员未能反问道另一个成员，就会将其标记为UNKNOWN状态。

g）REMOVED：表示此成员已经被从副本集中移除。

h）ROLLBACK：表示该成员正在回归数据

5 回滚

如果主节点执行一个写操作之后就停止了运行，而从节点还没来得及复制此操作，那么新选举出的主节点可能会丢失这个写操作。如果节点恢复同步其他数据源时，找不到改操作则会进入回滚然后恢复同步。MongodDB4.0之前回滚数据量上限为300MB，且时间为30分钟内。MongodDB4.0之后就没有回滚限制了。