最近 MongoDB 群里面有群友遇到2次重启 MongoDB 后一直处于实例恢复状态(应用 OPLOG )，多达几天甚至更长才完成重启，通常 MongoDB 副本集三个实例作为标准，重启主库会发生重新选出新主节点(通常在12s内完成)重新对外服务，通常不符合官方标准化或者内部发生异常导致的。经过了解副本集采用 PSA 架构且存在一个数据从节点不可达的情况(甚至有的从节点宕机几个月没有发现)，来分析这些情况以及如何应对。

主要包括以下内容：( WT 存储引擎下版本是3.2、3.4、3.6、4.0、4.2为主，4.4、5.0也存在)。

• PSA 架构下从节点宕机后,重启主库为什么会这么久
• PSA 架构还有哪些问题
• PSA 架构下如何缓解内存压力以及推荐 PSS 方案
• 模拟 PSA 架构下重启主库实例后长时间等待的情况并通过不同方案来解决

二. PSA 架构重启主库为什么会这么久

备注:有个提前是从库宕机存在一定周期且在此期间产生大量的脏数据。

当数据节点宕机且 enableMajorityReadConcern ( WT 3.2版本开始默认开启)，内存压力增大，这里只是说内存压力增大，没有进一步说明影响，比如说压力超过内存限制后如何处理、对性能的影响以及超长时间等待重启之类。(由于没有源码能力,相关东西只能通过 jira 、专家交流以及自己实验来验证)。

2.2 为什么会造成主库内存压力？

1. 用于从副本集或者集群中读取数据时，能够允许读取到被大多数节点收到并被确认的数据，对应关系型数据库里面提交读。
2. 注意：这里只是允许而已(数据库提供的能力，3.2版本才开始支持)。
3. 客户端是否需要根据实际 readConcern 级别，不管我们是否需要这种 majorityReadConcern 级别，数据库 WT 引擎已经维护这些信息在内存中(默认是开启)。
4. 当 PSA 副本集中存在一个数据节点宕机时，主库内存中数据的 Majority commit point 是无法推进的，此时 checkpoint 是不能将这些数据持久化(内存中脏数据无法更新到数据文件中)，同时 OPLOG 会保留所有变更操作，如果从库宕机时间长且主库很忙，OPLOG 会增长很大(4.0版本开始会超过配置大小)。
5. PSA 此时 checkpoint 不能对 Majority commit point 后的数据进行持久化，主库必须维护最近 Majority commit point 的快照提供给读，所以内存压力会增大和内存使用，最终这些内存数据溢出，此时 MongoDB 利用 SWAP 技术将内存中置换到磁盘上(将内存数据置换到磁盘上 )，所以性能会下降，如从库宕机时间长，此时主库性能也慢，同时磁盘空间也会暴涨。可能会考虑重启实例(通常情况下重启能解决大部分问题)，那么实例可能重启需要等特几天甚至更长时间才能完成。因为数据没有持久化，重启的话就需要进行实例恢复，那么就会出现开头说重启好多天都没有完成的悲剧。重启过程这个问题会被无限循环。(4.4开始重构来缓解这个问题，使用

三. PSA 架构还存在哪些问题

PSA 相比 PSS 少一份副本数据，相对应就 cost down. 这个是最直接好处。例如三机房部署 PSA 架构的副本集或者分片，对应 A 的机器最低配即可，不需要消耗什么资源。通常三机房采用 PSSSA 或者 PSSSS ，发生故障时优先切换本地机房。

正常情况下 PSA 正常下运行与 PSS 架构下无差别。主要出现 S 节点不可达以及长延迟情况会存在异常，除了内存压力增大造成性能的影响以及跟超长等待时间重启外,还如下常见场景:

writeConcern 或者 readConcern 为 majority ，读写会异常。majority 表示数据被副本集成员中大多数节点收到并被主确认。5.0之前版本默认 w:1，表示被主节点确认后表示操作成功,此时此群出现故障可能会导致写入主节点被回滚，从而造成数据丢失。所以 w:majority 是保证集群数据故障时不丢失的必需配置。

那么 majority 到底是多少个节点？对于 majority 是怎么计算？为什么 PSA 架构下宕机一个数据节点就不满足 majority ?

majorityVoteCount 来看。如果此时宕机一个数据节点或者不可达时，此时 majority 还是2，不会因为状态的改变而减少 majority 个数。此时需要满足 w:majority 的操作要不超时要不永不返回的状态。

注意：此时数据已经写入主节点，不管是超时还是永不返回，数据不会被回滚(不考虑事务的场景以及 failover 情况)。

同理3.2版本开始默认开启 enableMajorityReadConcern ，此时 majority commit point 也不会被推进。所以说 PSA 在一定程度上通过节约成本来降低系统高可用性。当然，说没有显式开启 majority ，是不是就没有问题？当存在一个数据节点不可达时，有些潜在场景默认是 majortiy 配置且不能修改，例如5.0开始

• 分片集群数据平衡，源或者目标分片中不能满足大多数成员时，数据平衡或者扩缩分片都会失败。分片集群管理，例如 shardCollection 、 dropIndex 等要求 majoriy 都会失败。分片集群下 changeStream 同样会无法捕获最新数据造成同步延迟。

如果从库已经宕机 N 时间，此时主库也宕机了，如果运维人员先启动老的从库，那么会"丢 N 时间"数据，这个数据存在在原主库，此时原主库启动后需要先回滚 N 时间数据才能重新加入到副本集中，通常回滚有限制，大概率会回滚失败。

四. 如何缓解内存压力

1. 避免一个数据节点实例宕机情况下对系统的影响，通过完善的监控及时发现节点异常(宕机、延迟)，及时处理故障，否则无能为力。
2. 临时将异常从库的优先级别与投票都设置为0(5.0版本由于不能禁用 MajorityReadConcern ，注意这个只能修改下应对从库宕机或延迟时，来缓解主库内存压力以及解决一些配置 majority 场景，但失去高可用，因为从库不能被选为主。适用场景是数据库需要重启时存在大量脏数据刷盘或者应用配置 w:majority 时,修改宕机实例优先级别与投票为0后进行重启才可以，如果已经重启的实例,此时只能等待)。

总结： PSA 解决从库宕机后如何缓解主库内存压力,通过有效监控及时消除故障点,如果没有及时发现,在重启前通过方案3来避免长时间重启问题，针对方案2需要提前规划好，但对于 majority 场景以及分片模式下操作还是无能为力，如果从库宕机很久，此时已强制重启主库,此时只能进入躺平状态去等。其他解决方案需要具体问题具体分析，例如只要系统能写入数据即可，可以把从实例恢复起来或者搭建空实例。

尽管通过禁用参数或者修改配置来缓解问题，但存在潜在的问题或者不熟悉的人还是会遇到同样问题，条件允许情况下，应使用 PSS 取代 PSA 架构能够解决单一数据节点宕机带来的影响。如果正在使用 PSA 架构也没有关系,知道存在问题即可，出现问题能够知道带来的影响是什么即可。

五. 场景模拟解决方案

备注：搭建4.2 PSA 副本集，手动 S 实例关闭并通过 POC 压测数据,构造20个字段1.1亿表。

5.2 查看磁盘上文件大小

5.4 查看内存压力情况

根据 rs.config 里面相关时间来判断：重启实例需要12号11点30分来恢复数据。根据 checkpoint 时间点来看：数据并没有持久化.但oplog持久化了。

如果此时重启，需要追1天 oplog ，需要从库停了一周，那么需要更久实例恢复，通常来说，重启是一件很常见事。

5.6 在不知道的情况下重启服务器

5.6.1 重启实例进入等待模式

备注：启动实例后进入无限等待时间窗口，在默认情况下 PSA 中 S 宕机多久，重启主库就需要不一定等比例时间，取决于多少脏数据以及服务器性能，因为进行 OPLOG 回放是并行，也许就是一个简单维护重启操作造成业务可能停机以天为级别的等待窗口。之前群里面遇到重启需要2天+等待窗口，正常业务肯定无法接受。登陆到数据库直接关闭主实例会报错(因为此时数据只有1个主+1仲裁)，此时就应该注意到异常，也可能忽略这个错误，只重启即可。如果知道重启会遇到问题,就不会冒然重启。

• 压测程序：5个小时构造插入记录。

• 恢复时间：并没有需要5小时，因为纯插入，恢复日志每一个 batch 接近5000。我们正常相对复杂点。所以真实业务恢复起来会慢的。Applied operations in 23035 batches 。

5.7 此时该如何做？

备注：此时系统重要指标：RPO、RTO 以及最终 SLA 指标。

需要多久能恢复到最新数据时间点来提供服务(不允许丢失数据)。需要天级别的恢复，这个对应级别就很低了。这个还不是容灾灾难恢复,此时只能等待，运维压力山大。

需要最快恢复系统来提供服务(系统可用性优先) 。重新搞一个新实例就可以或者重启从库。对应丢失数据来换取系统可用性,例如日志类。

5.7.2 后续如何解决这个问题

备注：如无法使用 PSS 代替 PSA 架构，参考前面讲过2点。

修改从节点的 vote 和 priority 为0，这个只适合临时针对实例宕机或者存在大延迟情况下降低主库的内存压力。否则此时PSA下主库宕机无法选出新主，失去天生高可用特性。

结论：经过前面讲解，我们知道 PSA 在宕机一个数据节点下才存在相关问题，如果 PSA 实例都是正常，我们无需担心这些问题。但实例宕机或者服务器故障不是我们能控制，需要考虑这种情况下，我们需要通过何种方式来解决这些问题。当系统出现问题时，第一种方案不太合适，只能适合下一次。相对第二种可以临时解决问题。

方案1：禁用 majorityReadConcern 参数，来缓解内存压力但无法解决其他问题，需要重启实例下一次才生效。

结论：通过禁用 majorityReadConcern 后，第一次重启还是花费30分钟，第二次重启就瞬间完成启动。但无法解决第一次重启长时间等待问题，需要预先规划并修改参数，当遇到问题时直接重启即可。在 PSA 架构出现数据节点宕机避免对主节点内存压力。但存在 majority 的场景还是无法解决，甚至 changestream 、分片集群下部分功能失效，重要系统还建议 PSS 架构。

方案2：临时将异常从库的优先级别与投票都设置为0来恢复。

当时北京时间：9号21点(最新时间)

OPLOG应用时间以及持久化时间：9号21点(最新时间)

上一个稳定恢复点时间：7号15点32分

根据 rs.config 里面相关时间来判断：重启实例需要7号15点32分来恢复数据。同时根据 checkpoint 时间点来看：数据并没有持久化。但 oplog 持久化了。此时重启需要从7号开始。

修改宕机的节点优先级别与投票都位0方案1。

• 修改从库的优先级与投票。

• 经过24分钟刷盘后，checkpoint 终于成功推进。

备注：共20分钟刷97G。包括索引与集合2部分，其实刷时间也挺久的，比重启快10分钟，相对来说比重启影响小很多。

总结：至此完成分析 PSA 架构存在问题以及对应方案,不管怎么应对，当单个数据节点宕机或者长延迟时，在一定程度上牺牲高可用性。在知道 PSA 架构优缺点后，需要在数据一致性与可用性做折中考虑,从5.0开始默认writeConcern从w:1变成 majority 。说明 MongoDB 在设计上更加关注数据一致性，这个改变实际从4.4版本就埋下种子，4.4版本开始 oplog 从默认拉取变成推送模式，在一定程度改善延迟问题。所以说在条件允许下，尽量采用 PSS 架构。但 5.0 PSA 默认 WriteConcern 变成 w:1。有个计算公式：

5.0分片集群采用 PSA 出现S宕机时，客户端写入 hang ，并没有按官方文档描述那样 PSA 默认写是 w:1。当初只是验证 PSA 副本集发现与官方描述一致，但并没有验证分片架构，导致存在偏差。

备注：关闭一个数据节点后写入是否正常。

指定写入失败，说明默认 majority 而是官方说 w:1。

6.1.3分片使用单个PSA shard来验证来验证默认写关注级别

6.1.4 正常情况插入测试数据。

6.1.5 模拟PSA副本中S宕机的场景来插入数据

备注：手动关闭从实例。

异常：此时没有指定 writeConcern ，采用默认的行为.此时写入 hang 住。

6.1.9 5.0 PSA 出现 S 宕机时，为了避免上一篇文章提到问题外。还包括如下:

如果客户端没有指定 writeConcern 采用默认行为会导致写入 hang 的情况应对措施:

采用方案2。注意是临时的，等从库恢复及时重置回去，否则当主库宕机，没有办法选出新主，从而影响系统可用性，此时从宕机或者机器挂了，需要及时监控并修改配置，否则可能会影响应用使用。

修改 config 默认 writeConcern 为 w:1 虽然能解决写入 hang 问题，但无法解决底层分片内存压力以及性能下降问题等问题。

6.1.10 修改分片中宕机的实例节点信息来验证写入

注意应：用此时指定 w:2 就有问题。

总结：至此完成分析 PSA 架构包括集群下使用 PSA 分片存在问题以及对应方案不管怎么应对都需要注意潜在的影响。例如当单个数据节点宕机或者长延迟时可，以通过程序定时检测节点状态出，现异常时临时将优先级别与投票设置0来避免5.0分片集群下默认多节点写入导致 hang 或者客户端指定多节点写入 hang 问题由，此带来一致性问题与高可用性问题需要关注的。

MongoDB 中文社区成员，数据库工程师，具有丰富的数据库运维经验，精通数据库性能优化及故障诊断，目前专注于 MongoDB 数据库运维与技术支持，同时也是公众号《 DB 说》维护者，喜欢研究与分享数据库相关技术。希望能够为社区贡献一份力量。