Ubuntu环境MongoDB升级至4.4.14后连接中断报错排查咨询

报错本质 #

你看到的HostUnreachable: Connection reset by peer不是MongoDB服务端自身故障，核心含义是：服务端完成操作准备向客户端返回响应时，发现TCP连接已经被客户端侧主动断开了。

问题1：是否为业务代码故障，如何定位修复 #

这类日志绝大多数场景不属于业务故障，仅少数情况和代码逻辑有关：

• 最常见的触发原因是Node.js驱动连接池的正常空闲回收。你使用的nodejs 4.6.0驱动默认会回收闲置超过30秒的连接，回收时直接发送TCP RST包断开链路，如果此时MongoDB刚好要在这个连接上回包（比如心跳响应、刚好执行完的查询结果），就会打印该日志。你提供的关联日志里，连接建立20秒后被断开、无对应业务操作报错的特征，完全符合空闲连接回收的表现。
• 少数触发原因是业务代码主动中断操作：比如给查询设置了过短的超时时间（maxTimeMS、请求超时）、提前关闭了游标、请求链路中断时直接销毁数据库客户端没等待执行中的操作返回，都会导致服务端回包时发现连接已断开。

定位和修复方法：

• 先比对日志量级和业务侧实际报错量：如果业务接口没有出现对应的数据库操作失败报错，这类日志就是连接池正常行为导致的，不需要做业务代码修复，只要调整连接参数即可：将驱动侧的maxIdleTimeMS配置调整到和服务端TCP keepalive时间（默认300秒）接近，避免驱动提前断开空闲连接。
• 如果业务侧确实存在偶发的数据库操作失败，按以下步骤排查：
  • 检查驱动连接配置，不要将socketTimeoutMS、serverSelectionTimeoutMS设置得过短，要大于你业务里最长的正常查询耗时。
  • 给所有常用查询加对应索引，把查询耗时降到超时阈值以内，避免查询还没返回就触发超时断连。
  • 排查代码逻辑，不要在查询执行过程中主动调用cursor.close()、销毁数据库客户端实例，等操作返回后再做资源回收。

问题2：是否为日志误报，如何屏蔽 #

这不是误报，是版本日志规则调整导致的：

• MongoDB 4.2版本中，这类客户端主动断连的日志默认属于DEBUG级别，不会输出到常规INFO日志中；4.4版本将日志ID为22989、20883的两类客户端断连日志调整到了INFO级别，所以升级后才会大量出现，日志表述完全准确，不存在误导。

屏蔽这类日志不需要重启服务，在线调整日志级别即可：

1. 临时生效可直接在mongo shell执行命令：

db.adminCommand({
  setParameter: 1,
  logComponentVerbosity: {
    network: {
      verbosity: 1,
      message: {
        22989: 0,
        20883: 0
      }
    }
  }
})

2. 永久生效需要在mongod.conf中添加对应配置：

systemLog:
  logComponentVerbosity:
    network:
      verbosity: 1
      message:
        22989: 0
        20883: 0

配置生效后，这类正常客户端断连的日志会被屏蔽，真正的网络故障、服务端连接异常类日志不会受影响，不影响日常问题排查。

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