ReactiveMongo适配MongoDB PSA架构的两类技术问题咨询

我有一个采用主-从-仲裁者（PSA）架构的MongoDB副本集，同时运行着基于Play v2.8框架、使用ReactiveMongo 1.0.10版本的Web应用，连接字符串如下：

mongodb://<user>:<pass>@mongo-pri:27017,mongo-sec:27017,mongo-arb:27017/<db>?authenticationMechanism=scram-sha1&connectTimeoutMS=20000&rm.nbChannelsPerNode=2000&replicaSet=<replica-name>&w=1&rm.keepAlive=true

技术问题 #

问题1：仲裁节点不可查询警告 #

ReactiveMongo抛出警告，提示仲裁节点不可查询，但该仲裁节点本就未配置账户和数据，也不允许登录，警告日志如下：

[WARN] from reactivemongo.core.actors.MongoDBSystem in reactivemongo-akka.actor.default-dispatcher-8 - [Supervisor-2/Connection-1] Node Node[mongo-arb:27017: NonQueryableUnknownStatus<14689291898971648ns> (200/200/200 available connections), latency=6ms, authenticated={}] has been not queryable for at least 300s; Removing it from the set! Please check configuration and connectivity

问题2：移除副本集相关节点后的合理性疑问 #

主节点与从节点位于不同场所，通过OpenVPN连接。近期在Play应用中新增了图片处理批处理任务，并创建了独立执行上下文，随后出现大量ReactiveMongo异常导致应用停滞，必须重启才能恢复。但此时用Studio3T或mongo shell仍可正常查询主节点。移除连接字符串中的从节点、仲裁节点及副本集名称后，系统恢复稳定。由于从节点仅用于备份，实际不需要故障转移功能，请问该操作是否合理？相关异常日志如下：

reactivemongo.core.actors.Exceptions$InternalState:
        at reactivemongo.ChannelConnected(4cd9fd04, {{NodeSet Some(sonobrain-rs) Node[mongo-pri:27017: Primary<17536106174783815ns> (2000/2000/2000 available connections), latency=3s, authenticated={scoliouser@scolionet}] | Node[mongo-sec:27017: Secondary<17536106177898008ns> (1396/1396/2000 available connections), latency=17536120s, authenticated={scoliouser@scolionet}] | Node[mongo-arb:27017: NonQueryableUnknownStatus<17536106209721144ns> (1213/1213/2000 available connections), latency=17536119s, authenticated={}] }})(<time:17536121496542193>)

针对问题1的解决思路 #

ReactiveMongo在副本集模式下会主动校验所有列出节点的可用性和状态，包括仲裁节点。你的仲裁节点未配置认证账户，导致ReactiveMongo无法完成节点状态验证，所以抛出警告。

可选解决方式：

• 直接移除连接字符串中的仲裁节点：如果后续不需要副本集故障转移功能，删掉mongo-arb:27017就能消除这个警告。
• 给仲裁节点配置认证账户：如果要保留副本集连接模式，需要在仲裁节点上创建和主从节点一致的认证账户，让ReactiveMongo能正常校验节点状态。

针对问题2的合理性说明 #

这个操作完全合理，原因如下：

1. 匹配业务需求：你明确从节点仅用于备份，不需要故障转移，单节点连接模式完全能满足当前业务要求。
2. 定位异常根源：从日志能看到从节点延迟异常高（17536120s），这是因为主从跨场所通过OpenVPN连接，网络稳定性差，加上新增的批处理任务占用大量连接资源，导致ReactiveMongo的连接池耗尽、节点状态校验失败，最终引发应用停滞。而Studio3T或mongo shell用的是简单连接模式，不会持续维护副本集所有节点的连接和状态，所以能正常访问主节点。
3. 保障系统稳定性：单节点连接模式下，ReactiveMongo只会维护与主节点的连接，避免了跨网络节点的状态校验和额外连接消耗，系统自然恢复稳定。

补充：如果后续需要恢复备份功能，只需确保从节点正常同步主节点数据即可，不需要在应用端配置副本集连接，备份操作可以用MongoDB自带的mongodump工具或者第三方备份服务完成。

内容的提问来源于stack exchange，提问作者Joseph Hui