replSetHeartbeat failed 错误基本由时间不同步引发，节点间时钟偏差超10秒会导致主节点降级、选举失败；偏差2–3秒在高负载下亦可触发超时，仲裁节点时间不准同样致命；oplog时间戳跳变会引发OplogStartMissing等不可自动恢复错误，须清空数据目录重同步。
replSetHeartbeat failed 错误基本就是时间不同步的信号
只要看到 replSetHeartbeat failed、HostUnreachable 或突然出现 NotMasterOrSecondary，且网络层（TCP 握手、端口连通性）确认正常，第一反应该查时钟。MongoDB 副本集心跳默认超时仅 10 秒，节点间系统时间偏差超过这个值，就会互相拒收心跳包——不是网络断了，是“时间对不上”，直接判定对方不可信。
- 偏差 >10 秒：主节点大概率被降级为
SECONDARY，集群进入持续选举状态 - 偏差 2–3 秒：高负载下因处理延迟叠加，仍可能触发超时，尤其在 oplog 密集写入时段
- 仲裁节点（Arbiter）时间不准一样致命——它不存数据，但一票否决权照常生效
oplog 时间戳跳变导致同步中断无法自动恢复
副本集靠 oplog 的 ts 字段（Timestamp 类型）保证操作顺序。若从节点系统时间突然回拨（比如手动执行 date -s、云主机休眠后未同步 NTP、容器未挂载宿主机时钟），它可能收到一个 ts 小于本地最新 oplog 记录的时间戳。MongoDB 会认为这是“历史重放”，直接中止复制并报错 OplogStartMissing 或 Cannot use plan cache。
- 这类错误不会自动恢复，删掉数据目录再初始同步是唯一办法
- 手动
ntpdate -u是步进校正（jump），风险极高；必须用chronyd平滑调整（slew） - 检查是否已发生跳变：对比
db.printReplicationInfo()中的oldest时间与系统当前时间
怎么验证和配置 NTP 才算真正安全
光装 chrony 不够，得确认它在平滑运行、源可靠、偏差可控。NTP 配置不当比没配更危险——ntpd -gq 这类步进命令在生产环境等同于埋雷。
- 必须统一所有节点（含 Arbiter）指向同一个 stratum ≤3 的 NTP 源，例如
pool.ntp.org或内网 NTP 服务器 - 检查同步状态：
chronyc tracking看Last offset是否稳定在 ±50ms 内；chronyc sources -v确认 source 状态为*（优选）或+（可用） - 禁用
systemd-timesyncd，它默认精度低、无平滑能力，与chronyd冲突 - 容器部署时，务必挂载宿主机时钟：
-v /etc/localtime:/etc/localtime:ro，否则容器内时间永远漂移
时间差太大时，别硬等自动修复
如果节点已处于 RECOVERING 或 STARTUP2 状态很久，rs.status() 显示 optimeDate 落后主节点数小时以上，大概率 oplog 已被覆盖。此时强行等待只会卡死，必须人工干预。
- 先停 mongod：
sudo systemctl stop mongod - 清空数据目录（如
/var/lib/mongodb），保留mongod.lock可删 - 启动后观察日志，确认进入
INITIALIZING→LOADING→SECONDARY - 切勿在同步完成前执行
rs.stepDown()或修改配置，会中断初始同步流程
时间同步不是“设完就完”的配置项，而是每个节点持续运行的前提。哪怕只漏掉一台仲裁机、一次容器重启没挂载时钟、一次手动调时，都可能让整个副本集在毫无征兆的情况下失去主节点或停止复制。
