负载升高时MongoDB读请求异常访问从节点原因排查

这不是日志打印偏差，从节点上的操作记录是真实执行的；也不是主节点主动转发请求，本质是MongoDB驱动与服务端配合的长游标隐式重路由机制触发，和你显式配置的primary读偏好不冲突，具体逻辑如下：

• 初始find请求确实全部发往主节点：collection.find()执行时只会构造游标，第一批结果拉取的find命令严格遵循你配置的primary读偏好，这和你调试模式下的观测、客户端驱动日志的记录一致。
• 你漏了后续getMore请求的日志：MongoDB游标不会一次性返回所有匹配结果，第一批结果返回后，后续批次的数据拉取靠独立的getMore命令完成。绝大多数驱动的默认日志级别只会记录初始find命令的路由信息，不会追踪每个getMore的发送目标，所以你会误以为所有请求都发往主节点。
• 高负载下触发隐式重路由：当非调试模式下请求速率高、游标迭代密集，主节点会判定该大结果集查询占用过高负载，会在给驱动的响应中携带重路由标记，建议驱动将同游标的后续getMore请求发往同步延迟符合要求的从节点。驱动接收到该标记后，会临时将该getMore请求的读偏好设置为secondaryPreferred，自动选择合适的从节点发送请求——这个过程是驱动和服务端的内置协商逻辑，不需要业务代码显式配置读偏好，这就是从节点日志中出现secondaryPreferred标记的原因。
• 调试模式下不触发的原因：逐行调试时游标迭代间隔极长，主节点不会判定该查询为高负载大查询，不会返回重路由标记，因此所有getMore都固定发往主节点，不会出现从节点访问记录。

你可以通过两个方式确认根因：

• 将客户端驱动的日志级别调到最细（比如TRACE级别，开启协议层请求日志），就能观测到后续getMore请求实际发往的节点地址
• 对比主从节点日志中同一条查询的cursor ID，会发现从节点上执行的操作对应的cursor ID，和主节点初始find返回的cursor ID完全一致，属于同一个游标。

如果要完全禁止读请求落到远程从节点，推荐两种可靠方案：

• 副本集侧配置：将远程从节点设置为hidden: true、priority: 0的隐藏节点，隐藏节点不会被驱动的自动路由逻辑选中，哪怕触发重路由也不会访问该节点
• 客户端侧配置：除了设置读偏好为primary外，额外给本地节点配置专属标签，在读偏好规则中显式指定只匹配本地标签的节点，从路由规则层面排除远程节点。

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