心跳检测默认每2秒一次，超时阈值为10秒；_heartbeatintervalmillis不可运行时修改，真正应调的是heartbeattimeoutsecs以应对网络抖动，验证需查replsetgetstatus中的lastheartbeatrecv差值。
心跳检测默认是每2秒一次，超时阈值是10秒
MongoDB复制集节点之间靠心跳维持彼此可见性，不是“等出问题才查”，而是持续、主动探测。默认情况下，每个节点每 2000 毫秒（即 2 秒）向其他成员发一次心跳请求；如果连续 10 秒没收到响应，就标记对方为不可达——这个 10 秒是 heartbeatTimeoutSecs 默认值，和心跳间隔是两回事。
_heartbeatIntervalMillis 能调，但不建议手动改
该参数控制心跳发送频率，单位毫秒，默认值是 2000。它属于内部可调参数，可通过 rs.conf() 查看，但不能直接用 rs.reconfig() 修改（会报错 “not allowed to modify heartbeatIntervalMillis”）。MongoDB 3.6+ 已将其设为只读字段，仅在初始化复制集时由启动参数 --replSet 隐式影响，运行中不可变更。
- 强行修改配置会触发复制集重配置失败，甚至导致节点拒绝加入
- 缩短间隔（如设为
500）不会提升故障发现速度，反而增加网络和 CPU 开销，尤其在跨机房部署时易引发误判 - 拉长间隔（如设为
5000）会让故障感知延迟变高，自动故障转移时间从平均 10–20 秒拉长到 30 秒以上
真正该调的不是心跳间隔，而是超时容忍度
实际运维中遇到“主节点明明活着，却频繁触发选举”，往往不是心跳太慢，而是网络抖动导致偶尔丢包，让节点误判对方失联。这时应优先考虑调整的是容错窗口，而非心跳频率：
- 通过
rs.reconfig()修改成员配置中的heartbeatTimeoutSecs字段（注意：是秒，不是毫秒），例如设为15，可缓解短暂网络波动带来的误切换 - 该值必须所有节点一致，否则选举逻辑可能混乱；且不能超过
electionTimeoutMillis / 2，否则选举器可能提前放弃投票 - 配合
priority和votes控制谁有资格参选，比调心跳更治本
验证心跳是否正常，别等出事才查
心跳状态藏在复制集状态输出里，不是日志里翻半天就能定位的。最直接的方式是连上任意节点执行：
db.adminCommand({replSetGetStatus: 1})
重点关注每个成员的 lastHeartbeat 和 lastHeartbeatRecv 时间戳差值——如果差值稳定在 2 秒左右，说明心跳通；如果某成员的 lastHeartbeatRecv 停滞超过 10 秒，且 stateStr 变成 UNKNOWN 或 DOWN，那就是心跳断了。
另外，db.runCommand({replSetGetStatus: 1}) 返回里的 pingMs 是驱动测得的往返延迟，它参与选举权重计算，也影响读偏好路由——这个值飘得厉害，比心跳间隔不准更值得警惕。
心跳机制本身很稳，但它的信号会被网络、防火墙、DNS 解析卡顿悄悄污染；与其纠结 _heartbeatIntervalMillis，不如先确认各节点间 TCP 连通性、NTP 时间同步、以及 mongod 进程是否被系统 OOM killer 杀过。
