# 1环境信息
系统名称
架构 DM8 数据守护集群（一主两备 + 确认监视器），组名 GRP1，自动切换模式（DW_MODE=AUTO）
服务器信息 Kylin Linux Advanced Server V10 (Halberd)
故障节点 RW1（19.xxx.188.183）
RW2（19.xxx.188.184）
RW3（19.xxx.188.185）
监视器 19.xxx.188.182
故障时间 2026年8月5日 03:25~03:30
业务恢复时间 2026年8月5日 03:30（RW2 自动接管后业务通过服务名无感恢复）

2故障描述

2026年8月5日凌晨3点25分起，各节点守护进程日志先后出现大量连接超时告警，守护进程按超时规则强杀并重启本地实例。03:29:57 确认监视器判定主库 RW1 故障，自动接管：RW2 升为新主库，业务随即恢复。
接管后旧主库 RW1、备库 RW3 反复拉起均被分裂防护强制关闭，无法归队。上午人工完成 RW1 降级归队，RW3 停摆待重备。

3故障分析

3.1守护进程日志排查

RW2 守护进程日志：03:25:26.305 同一毫秒内与本地实例、RW1、RW3、监视器的 4 条连接全部 “Tcp msg send over (10)s” 超时关闭；03:25:26.945 本地实例恢复，距上次接收本地实例消息间隔 143 秒（正常心跳为秒级），RW1 被置为 ERROR。
Tpc连接超时

守护进程与实例时间间隔：

RW3 守护进程日志：03:27:39.051 出现同样现象，距上次接收本地实例消息间隔 249 秒，RW1、RW2 同时被置为 ERROR，守护进程强杀并重启本地实例。
Tcp连接超时：

守护进程与实例时间间隔：

RW1出现同样情况：
守护进程与实例时间间隔：

三个节点先后出现相同的"长时间收不到消息"现象，时间点各自错开。

3.2实例日志排查

三个实例日志通过排查ERROR、FATAL等关键字，均无崩溃、无 core、无异常退出记录，实例都是收到守护进程 SHUTDOWN ABORT 指令后被强杀（RW2 03:25:26、RW3 03:27:53、RW1 03:29:57 各一条）。
数据库本身没有故障，是被守护进程"误杀"的。

3.3RW1故障与自动接管

RW1 守护进程日志 03:29:57.479：同样是与本地实例连接超时（距上次接收本地实例消息间隔 167 秒，连续两次广播间隔 167 秒），按规则 SHUTDOWN ABORT 本地实例，实例日志对应记录 utsk_dw_udp_bro used 167s。

03:29:57 确认监视器检测到 RW1 故障，判定 RW2 符合自动接管条件，03:29:58~03:30:00 执行接管，RW2 升为新主库，业务通过服务名无感恢复。

RW1 的"故障"与 RW2、RW3 性质相同，都是连接超时被误判，并非数据库崩溃。

3.4系统日志排查
三节点 messages 各有一条关键记录：
RW2=03:25:26、RW3=03:27:38、RW1=03:29:56 的 " Time has been changed"，与各节点守护进程超时时刻一一对应。08-03 03:00:25 chronyd 退出、ntpd 以 -g（允许大步校正）参数启动，时间调整为大步校时所致。
系统层面无 OOM、无进程被 kill、无磁盘及网卡故障。
RW1:

RW2:

RW3:

3.5自动接管后RW1，RW3无法正常运行故障分析

接管后组状态呈 GROUP SPLIT（组分裂），RW1和RW3节点起不来是组分裂。判决依据：RW1和RW3（pkg_seq 3704536999 / LSN 102806748491）比新主库 RW2（3704536998 / 102806748487）多 1 个包，LSN比RW2多4，双方数据不一致，而此时的RW1作为备库，它的数据进度反而比主库RW2还要超前，这就违背了数据同步的逻辑，因此就判定他分裂
守护进程日志显示数据不一致：

RW1：03:30:11 自动拉起后即被判分裂，03:30:16~17 守护进程连续 11 次判决 act(ACT_SPLIT) 并强制关闭实例；
03:30:28 第三次拉起同样被关，此后以 PRIMARY/MOUNT 空挂至 09:33。03:30:38 起监视器每张快照均标记 GROUP SPLIT，RW1 行 WCTLSTAT=SPLIT（监视器日志第 592、622 行）。
监视器显示分裂：

守护进程判定分裂：

一个节点被判定为分裂后，就会强制关闭实例，然后创建一个标记文件dmwatcher.ctl，这个文件会阻止实例的恢复
实例被强制关闭：

RW3：03:30:00 判 ACT_SPLIT 被 SHUTDOWN ABORT，此后每次拉起均被判分裂关闭，形成"启动→MOUNT→被关闭"死循环。
守护进程日志根据数据进度不一致判定它分裂：

实例日志判定它被关闭：

本质原因：RW2 于 03:25:26 被误杀重启，数据比 RW1、RW3 落后 1 个包；RW2 接管为新主后，另外两个节点的数据进度都比它要超前，违反了数据同步逻辑。

4原因总结

系统时间被大步校正 →
守护进程按心跳时间差误判节点失联（143s/249s/167s）→
误杀本地实例并重启 →
03:29:57 确认监视器判定主库 RW1 故障，AUTO 模式自动接管 RW2 →
切换后 RW1、RW3 本地数据比新主 RW2 多 1 个包，被判分裂防护（ACT_SHTDWN/ACT_SPLIT），反复拉起反复被关闭→
最后无法成功加入集群运行。

5故障处理及建议

RW1人工介入，进行日志截断+apply info 重建：

将RW1截断到比RW2数据进度更低的一个位置：
CLSN 102806748491 → 102804243040
pkg_seq 3704536999 → 3704432783
降级备库：

清理同步消息：

重新加入集群：

RW3等待人工重建
当前集群为"一主一备"运行：RW2（PRIMARY/OPEN）对外服务，RW1（STANDBY/OPEN）同步正常，RW3 节点全停。
后续建议：

1. 规范时钟管理：统一启用并锁死 NTP/chronyd 配置，禁止对守护集群节点执行 date -s 等人工校时；确需校时应提前评估对守护进程心跳判定的影响，建议停库或分步小步调整；
2. 分裂隐患治理：接管后发现旧主以 PRIMARY 状态空挂或组呈 SPLIT，应立即停机隔离，缩短双主风险窗口（本次空挂近 6 小时）；
3. 监控补强：对监视器 GROUP SPLIT 状态、节点 ERROR INSTANCES、系统时间变更建立告警，第一时间通知运维干预。