repmgr故障转移日志分析需串联“触发—决策—执行—确认”四阶段：起始点为“node x marked as down”等状态变更；决策阶段关注“quorum achieved”与超时比对；执行阶段识别“promoting to primary”及pg_is_in_recovery()变化；闭环信号是“successfully promoted to primary”及周期性“node status: primary”。
分析故障转移事件的完整链路日志，核心在于串联“触发—决策—执行—确认”四个阶段的日志信号，而非孤立查看某条报错。不同集群系统（如 PostgreSQL/repmgr、Redis、Windows Failover Cluster、K8s 等）日志结构各异，但追踪逻辑相通：必须明确时间线、节点角色变化、关键状态跃迁点和上下游依赖动作。
定位故障转移起始点
起始点通常是第一个异常信号，不一定是 ERROR，更可能是 WARNING 或状态变更提示：
- PostgreSQL/repmgr 中：关注 “failing over to node X” 或 “node Y marked as down” 这类语句，配合
log_status_interval设置的时间戳判断是否为首次检测失败 - Redis 集群中：“# Cluster state changed from ok to fail” 或主节点 shutdown 日志后紧随的 “failover triggered”
- Windows 故障转移群集：ETL 日志中 Event ID 1201（资源启动失败） 或 1135（节点被移出群集） 是典型起点，需用
wevtutil qe Microsoft-Windows-FailoverClustering/Diagnostic /q:"*[System[(EventID=1135)]]"提取 - K8s 中：Pod Terminating 日志 + 对应 StatefulSet 的 “Scaling down” 事件，再查 kube-scheduler 的 “Assumed pod” 和 controller-manager 的 “Updated status”
还原切换决策过程
这一阶段体现仲裁逻辑与健康判断，日志往往分散在多个组件：
- 检查仲裁日志：repmgr 的
repmgr cluster show输出需与日志中 “quorum achieved” 或 “not enough nodes online” 匹配；Windows 群集则看 Event ID 1177（仲裁丢失） 后是否出现 1069（服务启动失败） - 比对心跳与超时：Redis 的 “PONG reply not received” 间隔是否超过
cluster-node-timeout；repmgr 的 “last seen: X seconds ago” 是否超出failover_timeout - 确认主备状态变更：例如 repmgr 日志中从 “standby: ready” 到 “promoting to primary” 的跃迁，中间不应有长时间空白
追踪执行动作与副作用
执行阶段日志最易识别，但需注意副作用是否同步完成：
- 主节点切换后，立即检查新主库的 pg_is_in_recovery() = false（PostgreSQL）或 redis-cli cluster info | grep "cluster_state:ok"
- 关注连接重定向日志：应用端是否出现 “Connection refused” 或 “No route to host”，说明 VIP/Service DNS 更新滞后
- 验证数据一致性：Redis 中查看 “replicaof no one” 执行后，新主节点的 offset 是否与旧主宕机前一致；repmgr 则需确认
repmgr node status显示的 “upstream node” 已更新 - 检查资源接管：Windows 群集里，新主节点的磁盘资源是否成功 Online（Event ID 1222），SQL Server FCI 是否触发 “The SQL Server service is starting”（Event ID 17137）
验证最终状态与闭环信号
闭环日志是故障转移完成的标志，缺失即代表流程中断：
- repmgr：日志末尾出现 “successfully promoted to primary” 且后续周期性输出 “node status: primary”
- Redis：新主节点日志中持续出现 “Cluster state changed from fail to ok”，且所有节点
cluster nodes输出中该节点 role 为 master - Windows：Event ID 1207（资源在线）+ 1006（群集服务启动成功），且
Get-ClusterGroup显示资源组已迁移至目标节点 - K8s：新 Pod 的 “Started container” 日志 + Service Endpoint 更新日志（
kubectl get endpoints变更时间需与 Pod Ready 时间接近）
