心跳超时是内网高延迟或瞬时负载导致的误判，并非真实故障；需结合网络、资源、配置三方面优化，而非仅调大heartbeatTimeoutSecs。
为什么 replSetHeartbeat 日志频繁报超时，但副本集又没挂？
这不是 MongoDB 真的连不上，而是心跳检测在内网高延迟或瞬时负载下被误判。默认超时是 10 秒（heartbeatTimeoutSecs），但内网节点间 RTT 超过 500ms、CPU 突增或磁盘 I/O 堵塞时，replSetHeartbeat 请求可能卡在 socket read 阶段，触发日志告警。它不等于故障，但会掩盖真实问题。
-
rs.status()显示所有成员stateStr是PRIMARY/SECONDARY，说明复制正常 - 日志里反复出现：
replSetHeartbeat failed; HostUnreachable: Error connecting to ... (host unreachable)，但ping和telnet都通 - 问题多发于部署在 K8s 或 Docker 的副本集，尤其当容器共享宿主机网络带宽或 CPU 被限频时
怎么调 heartbeatTimeoutSecs 才不翻车？
不能直接改大 timeout 就完事——它会影响故障发现速度。比如从 10 秒改成 30 秒，主节点宕机后，从节点要等更久才发起选举，RPO/RTO 都变差。关键是让 timeout 匹配你的内网实际能力。
- 先用
mongostat --host <arbiter>观察各节点间netIn/netOut波动，确认是否真有周期性网络抖动 - 登录任意节点执行：
db.adminCommand({getCmdLineOpts: 1})，检查是否已通过--replSet参数传入自定义heartbeatTimeoutSecs - 修改必须在所有节点统一：停机后，在启动命令中加
--setParameter heartbeatTimeoutSecs=15（建议 12–18 秒区间） - 不要用
setParameter在线动态设置，它不生效于心跳逻辑，只影响部分后台任务
内网通信优化：别只盯着 MongoDB 配置
MongoDB 心跳走的是普通 TCP 连接，底层依赖操作系统网络栈和物理链路。很多团队调完 timeout 还是报警，是因为忽略了容器或虚拟化层的干扰。
- 宿主机上运行
ss -ti，观察 MongoDB 端口连接的rtt和retrans（重传次数），>1% 就说明链路不稳定 - Docker 部署时，避免用
bridge模式；改用host网络或 CNI 插件（如 Calico）确保 UDP/TCP 路径最短 - K8s 中给 MongoDB Pod 加
resources.limits.cpu（至少 2 核），防止 kubelet 因 CPU throttling 导致心跳响应延迟 - 禁用
tcp_tw_reuse和tcp_fin_timeout等激进回收参数——心跳连接是长连接，回收太快反而触发重连风暴
负载高导致心跳超时？先看这三处真实瓶颈
心跳请求本身很轻，但若 MongoDB 正在处理大量慢查询、WiredTiger cache 常驻满、或 journal 写入阻塞，主线程会被抢占，导致无法及时响应心跳包。
- 查
db.currentOp({secs_running: {$gt: 5}})，确认有没有 >5 秒未返回的查询卡住 oplog 处理线程 - 监控
extra_info.page_faults：持续 >1000/sec 说明 WiredTiger cache 不够，内存不足会拖慢所有操作，包括心跳应答 - 看
journal目录所在磁盘的iowait和await，>50ms 表明 journal 写入成了瓶颈，心跳响应自然排队 - 临时缓解可加
--setParameter disableLogicalSessionCacheRefresh=true（仅适用于 4.2+），减少后台 session 刷新对主线程争抢
真正麻烦的不是日志多，而是把心跳超时当成孤立问题去调参。它往往是网络、资源、配置三层耦合的结果——改一个地方，得同步验证另外两层是否还稳。
