故障转移故障排查手册：常见报错一站式解决

故障转移故障排查手册：常见报错一站式解决

故障转移(Failover)涉及的组件很多，但排查思路其实高度一致：先确认“是否真的触发了故障转移”，再定位“触发原因”，最后验证“切换后是否可用”。下面按通用排查流程 + 高频组件报错整理，适合做运维手册直接复用。

一、通用排查流程：先定时间，再定原因

1. 先锁定故障时间窗口

不要一上来翻日志，先看监控、告警、业务报错时间点。重点确认：

故障转移是否真实发生

主节点/主副本是否真的不可用

切换发生在哪个时间点

切换后业务是否恢复

是否出现脑裂、双写、数据回滚

2. 按四层日志定位

系统层：dmesg、/var/log/messages、syslog、Windows 事件日志，看 OOM、磁盘错误、网络中断、CPU/内存异常。

应用层：数据库、缓存、中间件 error.log，看连接失败、复制中断、健康检查超时。

集群层：Failover Cluster、Sentinel、Orchestrator、K8s Controller 日志，看选举、切换、资源迁移记录。

网络/存储层：心跳网络、VIP、防火墙、共享存储、PV/PVC，看连通性和存储读写是否正常。

3. 常用关键字

日志里优先搜：

bash

编辑

failover

fail

timeout

refused

denied

CLUSTERDOWN

RESOLVING

NOT SYNCHRONIZING

IsAlive has indicated failure

Online for resource failed

OOMKilled

ExitCode 137

二、Redis Cluster / Sentinel 常见报错

1. CLUSTERDOWN The cluster is down

现象：所有读写都返回 CLUSTERDOWN。

排查：

bash

编辑

redis-cli -h-p 6379 cluster info

redis-cli -h-p 6379 cluster nodes | grep fail

重点看：

cluster_state:fail

cluster_slots_ok 是否等于 16384

cluster_slots_fail 是否大于 0

常见原因：

有 slot 无主节点

超过半数 master 不可用

节点被误判下线后未恢复

处理：

先恢复失联节点或补新节点

使用 redis-cli --cluster fix 修复 slot

必要时在从节点执行 CLUSTER FAILOVER

生产环境谨慎使用 CLUSTER RESET，它会清空节点数据

2. 主从切换失败 / Slave 未自动晋升

现象：master 宕机，但 slave 没有接管。

排查：

bash

编辑

redis-cli config get cluster-node-timeout

redis-cli config get cluster-slave-validity-factor

grep -E "failover|FAIL|timeout" redis.log

常见原因：

cluster-node-timeout 过大，故障检测慢

slave 数据落后太多，被认为不适合晋升

slave 自身网络隔离或负载过高

Sentinel 未达成多数派共识

处理：

内网环境可将 cluster-node-timeout 适当调小

检查 cluster-slave-validity-factor，避免过严

在目标 slave 上执行 CLUSTER FAILOVER 手动切换

Sentinel 场景需保证至少 3 个 Sentinel，避免脑裂

3. 节点失联 / PFAIL / FAIL

现象：cluster nodes 中出现 fail 或 disconnected。

排查：

bash

编辑

redis-cli -h-p 6379 cluster nodes

redis-cli -h-p 6379 ping

telnet6379

常见原因：

网络分区

防火墙阻断集群总线端口

节点 OOM 或进程崩溃

DNS/路由异常

处理：

先恢复网络连通性

检查防火墙是否开放 Redis 端口和集群总线端口

节点恢复后观察是否自动重新加入

若发生脑裂，优先保留多数派数据，少数派重新以 slave 加入

4. MOVED / ASK 重定向异常

现象：客户端频繁收到 MOVED 或 ASK，部分请求失败。

排查：

客户端是否支持 Cluster 模式

是否缓存了过期 slot 映射

是否正在 reshard 或迁移 slot

处理：

使用支持 Cluster 的客户端

检查 cluster slots 是否稳定

避免在业务高峰执行 reshard

三、SQL Server AlwaysOn / Windows 故障转移集群

1. 自动故障转移失败，副本处于 RESOLVING

现象：SSMS 显示副本为 RESOLVING，数据库显示 NOT SYNCHRONIZING，应用报错 983。

排查：

powershell

编辑

Get-ClusterLog -Node <节点名> -TimeSpan 15

在 Cluster.log 中搜索：

text

编辑

failoverCount

Online for resource failed

IsAlive sanity check failed

Group move

Move of group

常见原因：

指定时间段内故障次数超过阈值

健康检查超时

租约超时

节点网络隔离

共享存储或 CSV 异常

处理：

检查 failoverCount 是否超过 computedFailoverThreshold

不要盲目调大“指定期间最大失败数”，先找到根因

检查 AlwaysOn 健康检查是否正常

检查 SQL Server 错误日志和 Windows 事件日志

2. 事件 ID 1069 / 1146 / 1230

这些是 Windows 故障转移集群常见事件 ID，通常表示资源失败、角色迁移或集群异常。

排查：

打开系统事件日志，筛选来源 Microsoft-Windows-FailoverClustering

对比系统日志时间与 Cluster.log 的 GMT 时间

搜索 The current time is 快速对齐时区

查看资源是否成功在目标节点上线

3. Online for resource failed

现象：资源迁移到新节点后无法上线。

常见原因：

依赖资源未就绪

共享存储不可访问

网络名称/IP 资源冲突

权限不足

应用本身启动失败

处理：

检查资源依赖链

检查 CSV/共享磁盘状态

检查集群服务账户权限

在目标节点手动尝试上线资源并观察报错

四、Kubernetes 场景常见报错

1. Pod CrashLoopBackOff

排查：

bash

编辑

kubectl describe pod

kubectl logs--previous

重点关注：

ExitCode 137：通常是被 OOMKilled

ExitCode 1：应用启动失败

配置错误、依赖服务不可用

启动探针/就绪探针失败

2. OOMKilled

现象：Pod 被杀死，Last State Reason 为 OOMKilled。

处理：

适当调高 resources.limits.memory

检查应用是否存在内存泄漏

Java 应用检查 -Xmx 与容器内存限制是否匹配

避免容器内存限制小于 JVM 堆内存

3. Pending

常见原因：

节点资源不足

PVC 未绑定

节点亲和性/污点不匹配

镜像拉取失败

排查：

bash

编辑

kubectl describe pod| grep -A 20 Events

kubectl get pvc

kubectl top nodes

4. Redis on K8s 集群配置损坏

现象：日志出现 corrupted cluster config file。

处理：

从集群中移除故障节点

清理损坏的 nodes.conf 和数据目录

重建 Pod 后重新加入集群

检查 PV/PVC 和存储健康状态

五、云灾备 / ASR 故障转移常见报错

1. 虚拟机故障转移到云失败

常见原因：

订阅配额不足

可用性集内虚拟机规格族不一致

订阅策略阻止创建虚拟机

网卡配额不足

前一次测试故障转移未清理，IP 冲突

处理：

检查计算、网络、网卡配额

统一可用性集内虚拟机规格族

清理失败的测试故障转移资源

检查目标网络、子网、NSG、DNS 配置

2. 故障转移后无法 RDP/SSH

排查：

检查 VM 是否真正启动

检查启动诊断日志

检查网卡是否绑定公网 IP 或私有网络是否可达

检查 NSG/安全组是否放行端口

域加入虚拟机需确认域控制器可用

六、快速排查命令速查

bash

编辑

# Redis

redis-cli cluster info

redis-cli cluster nodes

redis-cli config get cluster-node-timeout

redis-cli --cluster fix:

# K8s

kubectl describe pod

kubectl logs--previous

kubectl get pvc,pv

kubectl top nodes

# Linux 系统

dmesg -T | tail -100

journalctl --since "30 minutes ago"

grep -i "oom" /var/log/messages

# Windows 集群

Get-ClusterLog -Node <节点> -TimeSpan 15

Get-EventLog -LogName System -Source Microsoft-Windows-FailoverClustering

七、预防建议

每个 master 至少配一个 slave，并分散在不同可用区

关闭不必要的自动故障转移阈值告警，但保留根因告警

定期演练故障转移，验证切换时间和数据一致性

对 Redis 开启 min-replicas-to-write 等保护参数，降低脑裂风险

对 AlwaysOn 定期检查健康检查、复制延迟和故障转移历史

对 K8s 工作负载设置合理的 requests/limits 和探针参数