MongoDB故障码1150是一个和时钟同步直接相关的错误，典型表现是副本集节点频繁掉线、选举异常、日志中出现Clock skew相关的报错信息。不少运维人员在排查时会把注意力放在MongoDB配置和网络连通性上，结果折腾半天发现真正的元凶是服务器系统时钟偏差超过了允许范围。本文将从原理、排查、解决三个层面把这个故障讲透。
一、时钟偏差为什么会触发1150故障码
要理解这个故障，得先从副本集的工作机制说起。MongoDB副本集依靠心跳机制维持节点之间的联系，默认每2秒发送一次心跳，如果超过10秒没有收到某个节点的心跳，就会认为该节点失联。心跳包里携带着时间信息，节点之间会互相校对时间戳，一旦发现对方的时间与自己差距过大，MongoDB会直接判定对方状态异常，从而抛出时钟偏差错误。
另一个受时钟影响的关键组件是Oplog。Oplog是副本集数据同步的基石，其中每一条操作记录都带有时间戳，从节点根据Oplog时间戳来决定拉取哪些操作。如果主节点和从节点的系统时钟不一致，可能出现从节点认为某条Oplog记录来自未来的情况，同步流程会因此中断，严重时从节点会进入RECOVERING状态无法自动恢复。
MongoDB默认允许的时钟偏差上限是90秒，超过这个阈值就可能触发1150错误。在实际环境中，虚拟机长时间暂停后恢复、宿主机时钟漂移、手动修改过系统时间等操作，都是造成大偏差的常见原因。
二、如何定位时钟同步问题
排查的第一步是确认各节点当前时间。可以在每台MongoDB服务器上执行date命令对比结果，也可以在mongosh中查看：
// 查看服务器系统时间
db.serverStatus().localTime
// 查看副本集各节点状态
rs.status().members.forEach(function(m){
print(m.name, m.stateStr, m.optimeDate)
})
重点观察members数组中每个节点的optimeDate字段，如果某个节点的时间明显落后或超前于其他节点，基本可以锁定问题机器。除了时间比对，还应该检查MongoDB日志中的关键字：
grep -i "clock skew" /var/log/mongodb/mongod.log grep -i "1150" /var/log/mongodb/mongod.log
如果日志中出现Clock skew too far之类的记录，并且伴随节点在SECONDARY和RECOVERING之间反复切换的现象，就说明时钟偏差已经影响到了正常的复制流程。此时还可以用timedatectl命令检查系统的NTP同步状态，确认时钟服务是否正常工作：
timedatectl status # 重点关注 System clock synchronized 和 NTP service 两行
如果NTP service显示为inactive，或者synchronized为no，说明这台机器根本没在做时钟同步，长期运行后出现漂移是必然的。
三、彻底解决：配置可靠的时钟同步服务
解决方案的核心是给所有MongoDB节点配置统一且可靠的NTP时间源。目前主流选择有两个：传统的ntpd和更现代的chronyd，CentOS 8以上的系统默认已经换成chrony，推荐优先使用它，配置也更简单：
# 安装chrony yum install -y chrony # 编辑配置文件，指定时间服务器 vim /etc/chrony.conf # 添加或确认以下行（阿里云时间源） # server ntp.aliyun.com iburst # 启动并设置开机自启 systemctl enable --now chronyd # 查看同步状态 chronyc sources -v chronyc tracking
配置完成后，用chronyc tracking命令验证，System time一行如果显示正负几十毫秒以内的偏差，说明同步已经生效。所有副本集节点都要执行同样的配置，确保大家从同一个时间源校时。如果企业内网有自建NTP服务器，可以将各节点统一指向内网服务器，减少对外网的依赖。
时间同步完成后，之前异常的节点通常会在几分钟内自动恢复正常同步。如果某个节点长时间停留在RECOVERING状态无法自动追上，可能需要手动介入，评估数据差距后决定是等待回放Oplog还是重新初始化同步。
四、预防时钟漂移的运维建议
解决问题只是第一步，防止复发才更关键。针对MongoDB集群的时钟管理，有几点经验值得参考。第一，虚拟化环境要特别小心，VMware等平台的虚拟机在宿主机负载高或经历vMotion迁移后容易出现时钟跳变，务必在宿主机和虚拟机两层都启用时间同步，避免双重校时互相干扰。第二，把时钟状态纳入监控体系，可以用Zabbix或Prometheus的node_exporter采集各节点时间与标准时间的差值，设置超过30秒告警，这样能在偏差到达90秒阈值之前提前介入。
第三，规范运维操作，任何情况下都不要在生产服务器上直接执行date -s手动改时间，这种操作会造成时间跳变，对副本集的破坏比缓慢漂移更严重。第四，定期演练故障恢复流程，确认当某个节点因时钟问题掉线后，集群仍能维持多数派可用，避免单点时钟故障演变成整个集群不可写的事故。
总结来说，1150故障码本质上是MongoDB对底层时钟环境的一种保护性反应。只要保证所有节点时间源统一、同步服务常开、监控提前预警，这类问题完全可以做到防患于未然。
MongoDB故障码1150时钟同步分布式系统修改时间：2026-09-06 12:06:32