MongoDB——副本集的同步、选举和回滚

落日映苍穹つ 2023-10-09 22:27 26阅读 0赞

### 1、同步 ###

复制用于在多台服务器之间备份数据。MongoDB的复制功能是使用操作日志oplog实现的，操作日志包含了主节点的每一次写操作。oplog是主节点的locl数据库中的一个固定集合。备份节点通过查询这个集合就可以知道需要进行复制的操作。

每个备份节点都维护着自己的oplog,记录着每一次从主节点复制数据的操作。这样，每个成员都可以作为同步源提供给其他成员使用，如图所示。备份节点从当前使用的同步源中获取需要执行的操作，然后在自己的数据集上执行这些操作，最后再将这些操作写入自己的oplog。如果遇到某个操作失败的情况（只有当同步源的数据损坏或者数据与主节点不一致时才可能发生)，那么备份节点就会停止从当前的同步源复制数据。

![在这里插入图片描述][c8bf849817894bdfb78f15b7b19097bc.png]

如果某个备份节点由于某些原因挂掉了，当它重新启动之后，就会自动从oplog中最后一个操作开始进行同步。由于复制操作的过程是先复制数据再写入oplog,所以，备份节点可能会在已经同步过的数据上再次执行复制操作。

MongoDB在设计之初就考虑到了这种情况：将oplog中的同一个操作执行多次，与只执行一次的效果是一样的。  
由于oplog大小是固定的，它只能保存特定数量的操作日志。通常，oplog使用空间的增长速度与系统处理写请求的速率近乎相同：如果主节点上每分钟处理了1KB的写入请求，那么oplog很可能也会在一分钟内写入1KB条操作日志。但是，有一些例外情况：如果单次请求能够影响到多个文档（比如删除多个文档或者是多文档更新)，oplog中就会出现多条操作日志。如果单个操作会影响多个文档，那么每个受影响的文档都会对应oplog中的一条日志。因此，如果执行db.coll.remove()删除了1000000个文档，那么oplog中就会有1000000条操作日志，每条日志对应一个被删除的文档。如果执行大量的批量操作，oplog很快就会被填满。

##### 1.1、初始化同步 #####

副本集中的成员启动之后，就会检查自身状态，确定是否可以从某个成员那里进行同步。如果不行的话，它会尝试从副本的另一个成员那里进行完整的数据复制。这个过程就是初始化同步(initial syncing),包括几个步骤，可以从mongod的日志中看到。

1.  首先，这个成员会做一些记录前的准备工作：选择一个成员作为同步源，在local.me中为自己创建一个标识符，删除所有已存在的数据库，以一个全新的状态开始进行同步：注意，在这个过程中，所有现有的数据都会被删除。应该只在不需要保留现有数据的情况下做初始化同步（或者将数据移到其他地方)，因为mongod会首先将现有数据删除。
2.  然后是克隆(cloning),就是将同步源的所有记录全部复制到本地。这通常是整个过程中最耗时的部分
3.  然后就进人oplog同步的第一步，克隆过程中的所有操作都会被记录到oplog中。如果有文档在克隆过程中被移动了，就可能会被遗漏，导致没有被克隆，对于这样的文档，可能需要重新进行克隆
4.  接下来是oplog同步过程的第二步，用于将第一个oplog同步中的操作记录下来。
5.  到目前为止，本地的数据应该与主节点在某个时间点的数据集完全一致了，可以开始创建索引了。
6.  如果当前节点的数据仍然远远落后于同步源，那么oplog同步过程的最后一步就是将创建索引期间的所有操作全部同步过来，防止该成员成为备份节点。
7.  现在，当前成员已经完成了初始化同步，切换到普通同步状态，这时当前成员就可以成为备份节点了：

从操作者的角度来说，初始化同步是非常简单的：使用空的数据目录启动mongod即可。但是。更多时候可能需要从备份中恢复而不是进行初始化同步。从备份中恢复的速度比使用mongod复制全部数据的速度快得多。

克隆也可能损坏同步源的工作集(working set)。实际部署之后，可能会有一个频繁使用的数据子集常驻内存（因为操作系统要频繁访问这个子集)。执行初始化同步时，会强制将当前成员的所有数据分页加载到内存中，这会导致需要频繁访问的数据不能常驻内存，所以会导致很多请求变慢，因为原本只要在RAM(内存)中就可以处理的数据要先从磁盘上加载。不过，对于比较小的数据集和性能比较好的服务器，初始化同步仍然是个简单易用的选项。

初始化同步过程中经常遇到的问题是，第(2)步（克隆)或者第（⑤）步（创建索引)耗费了太长的时间。这种情况下，新成员就与同步源的oplog“脱节”：新成员远远落后于同步源，导致新成员的数据同步速度赶不上同步源的变化速度，同步源可能会将新成员需要复制的某些数据覆盖掉。  
这个问题没有有效的解决办法，除非在不太忙时执行初始化同步，或者是从备份中恢复数据。如果新成员与同步源的olog脱节，初始化同步就无法正常进行。

##### 1.2、处理陈旧数据 #####

如果备份节点远远落后于同步源当前的操作，那么这个备份节点就是陈旧的(stale)。陈旧的备份节点无法跟上同步源的节奏，因为同步源上的操作领先太多太多：如果要继续进行同步，备份节点需要跳过一些操作。如果从备份节点曾经停机过，写入量超过了自身处理能力，或者是有太多的读请求，这些情况都可能导致备份节点陈旧。

当一个备份节点陈旧之后，它会查看副本集中的其他成员，如果某个成员的oplog足够详尽，可以用于处理那些落下的操作，就从这个成员处进行同步。如果任何一个成员的oplog都没有参考价值，那么这个成员上的复制操作就会中止，这个成员需要重新进行完全同步（或者是从最近的备份中恢复）。

为了避免陈旧备份节点的出现，让主节点使用比较大的oplog保存足够多的操作日志是很重要的。大的oplog会占用更多的磁盘空间。通常来说，这是一个比较好的折衷选择，因为磁盘会越来越便宜，而且实际中使用的oplog只有一小部分，因此oplog不占用太多RAM。

### 2、心跳 ###

每个成员都需要知道其他成员的状态：哪个是主节点？哪个可以作为同步源？哪个挂掉了？为了维护集合的最新视图，每个成员每隔两秒钟就会向其他成员发送个心跳请求(heartbeat request)。心跳请求的信息量非常小，用于检查每个成员的状态。  
心跳最重要的功能之一就是让主节点知道自己是否满足集合“大多数”的条件。如果主节点不再得到“大多数”服务器的支持，它就会退位，变成备份节点。

##### 2.1 成员状态 #####

*  `STARTUP`  
    成员刚启动时处于这个状态。在这个状态下，MongoDB会尝试加载成员的副本集配置。配置加载成功之后，就进入STARTUP2状态。
 *  `STARTUP2`  
    整个初始化同步过程都处于这个状态，但是如果是在普通成员上，这个状态只会持续几秒钟。在这个状态下，MongoDB会创建几个线程，用于处理复制和选举，然后就会切换到RECOVERING状态。
 *  `RECOVERING`  
    这个状态表明成员运转正常，但是暂时还不能处理读取请求。如果有成员处于这个状态，可能会造成轻微的系统过载，以后可能会经常见到。  
    启动时，成员需要做一些检查以确保自己处于有效状态，之后才可以处理读取请求。在启动过程中，成为备份节点之前，每个成员都要经历RECOVERING状态。  
    在处理非常耗时的操作时，成员也可能进入RECOVERING状态。，比如压缩或者是响应replSetMaintenance命令。  
    当一个成员与其他成员脱节时，也会进入RECOVERING状态。通常来说，这时这个成员处于无效状态，需要重新同步。但是，成员这时并没有进入错误状态，因为它期望发现一个拥有足够详尽oplog的成员，然后继续同步oplog,最后回到正常状态。
 *  `ARBITER`  
    在正常的操作中，仲裁者应该始终处于ARBITER状态。

系统出现问题时会处于下面这些状态：

*  `DOWN`  
    如果一个正常运行的成员变得不可达，它就处于D0WW状态。注意，如果有成员被报告为D0WN状态，它有可能仍然处于正常运行状态，不可达的原因可能是网络问题。
 *  `UNKNOWN`  
    如果一个成员无法到达其他任何成员，其他成员就无法知道它处于什么状态，会将其报告为UNKNOWN状态。通常，这表明这个未知状态的成员挂掉了，或者是两个成员之间存在网络访问问题。
 *  `REMOVED`  
    当成员被移出副本集时，它就处于这个状态。如果被移出的成员又被重新添加到副本集中，它就会回到“正常”状态。
 *  `ROLLBACK`  
    如果成员正在进行数据回滚（详见10.4节)，它就处于R0 LLBACK状态。回滚过程结束时，服务器会转换为RECOVERING状态，然后成为备份节点。
 *  `FATAL`  
    如果一个成员发生了不可挽回的错误，也不再尝试恢复正常的话，它就处于FATAL状态。应该查看详细日志来查明为何这个成员处于FATAL状态（使用"replSet FATAL"关键词在日志上执行grep,就可以找到成员进入FATAL状态的时间点)。这时，通常应该重启服务器，进行重新同步或者是从备份中恢复。

### 3、选举 ###

当一个成员无法到达主节点时，它就会申请被选举为主节点。希望被选举为主节点的成员，会向它能到达的所有成员发送通知。如果这个成员不符合候选人要求，其他成员可能会知道相关原因：这个成员的数据落后于副本集，或者是已经有一个运行中的主节点（那个力求被选举成为主节点的成员无法到达这个主节点）。在这些情况下，其他成员不会允许进行选举。

假如没有反对的理由，其他成员就会对这个成员进行选举投票。如果这个成员得到副本集中“大多数”赞成票，它就选举成功，会转换到主节点状态。如果达不到“大多数”的要求，那么选举失败，它仍然处于备份节点状态，之后还可以再次申请被选举为主节点。主节点会一直处于主节点状态，除非它由于不再满足“大多数”的要求或者挂了而退位，另外，副本集被重新配置也会导致主节点退位。

假如网络状况良好，“大多数”服务器也都在正常运行，那么选举过程是很快的。如果主节点不可用，2秒钟（之前讲过，心跳的间隔是2秒)之内就会有成员发现这个问题，然后会立即开始选举，整个选举过程只会花费几毫秒。但是，实际情况可能不会这么理想：网络问题，或者是服务器过载导致响应缓慢，都可能触发选举。

在这种情况下，心跳会在最多20秒之后超时。如果选举打成平局，每个成员都需要等待30秒才能开始下一次选举。所以，如果有太多错误发生的话，选举可能会花费几分钟的时间。

### 4、回滚 ###

如果主节点执行了一个写请求之后挂了，但是备份节点还没来得及复制这次操作，那么新选举出来的主节点就会漏掉这次写操作。假如有两个数据中心，其中一个数据中心拥有一个主节点和一个备份节点，另一个数据中心拥有三个备份节点，如图所示。

![在这里插入图片描述][142e79d6a6cb444292f2d96ccdbf346b.png]

如果这两个数据中心之间出现了网络故障，如图所示。其中左边第一个数据中心最后的操作是126，但是126操作还没有被复制到另边的数据中心。  
![在这里插入图片描述][9f31792a4374476abb3438be513a8b52.png]

右边的数据中心仍然满足副本集“大多数”的要求（一共5台服务器，3台即可满足要求)。因此，其中一台服务器会被选举成为新的主节点，这个新的主节点会继续处理后续的写入操作，如图所示。  
![在这里插入图片描述][945319f840914814840d87792f06cddf.png]

网络恢复之后，左边数据中心的服务器就会从其他服务器开始同步126之后的操作，但是无法找到这个操作。这种情况发生的时候，A和B会进入回滚（rollback)过程。回滚会将失败之前未复制的操作撤消。拥有126操作的服务器会在右边数据中心服务器的oplog中寻找共同的操作点。之后会定位到125操作，这是两个数据中心相匹配的最后一个操作。下图显示了oplog的情况。

![在这里插入图片描述][0cb3c13c4d5d44329e0b275ad38da898.png]

这时，服务器会查看这些没有被复制的操作，将受这些操作影响的文档写入一个.bson文件，保存在数据目录下的rollback目录中。如果126是一个更新操作，服务器会将被126更新的文档写入collectionName.bson文件。然后会从当前主节点中复制这个文档。

服务器开始从另一个成员进行同步（在本例中是server-1),但是发现无法在同步源中找到自己的最后一次操作。这时，它就会切换到回滚状态（“replSet ROLLBACK”)进行回滚。

第2步，服务器在两个oplog中找到一个共同的点，是26秒之前的一个操作。然后服务器就会将最近26秒内执行的操作从oplog中撤销。回滚完成之后，服务器就进入RECOVERING状态开始进行正常同步。

##### 回滚失败 #####

某些情况下，如果要回滚的内容太多，MongoDB可能承受不了。如果要回滚的数据量大于300MB,或者要回滚30分钟以上的操作，回滚就会失败。对于回滚失败的节点，必须要重新同步。

这种情况最常见的原因是备份节点远远落后于主节点，而这时主节点却挂了。如果其中一个备份节点成为主节点，这个主节点与旧的主节点相比，缺少很多操作。为了保证成员不会在回滚中失败，最好的方式是保持备份节点的数据尽可能最新。

[c8bf849817894bdfb78f15b7b19097bc.png]: https://img-blog.csdnimg.cn/c8bf849817894bdfb78f15b7b19097bc.png
[142e79d6a6cb444292f2d96ccdbf346b.png]: https://img-blog.csdnimg.cn/142e79d6a6cb444292f2d96ccdbf346b.png
[9f31792a4374476abb3438be513a8b52.png]: https://img-blog.csdnimg.cn/9f31792a4374476abb3438be513a8b52.png
[945319f840914814840d87792f06cddf.png]: https://img-blog.csdnimg.cn/945319f840914814840d87792f06cddf.png
[0cb3c13c4d5d44329e0b275ad38da898.png]: https://img-blog.csdnimg.cn/0cb3c13c4d5d44329e0b275ad38da898.png