主备切换回滚应急预案须在切换前明确触发条件、操作路径和验证方式；触发条件包括服务异常、数据延迟＞5秒、业务指标恶化等；操作清单需预置可执行命令，回滚后须冒烟测试并校验数据；需隔离影响范围并定期演练验证。

主备切换时的回滚应急预案不是“切完再想怎么退”，而是必须在切换前就明确触发条件、操作路径和验证方式。核心是控制风险边界，确保一旦新主节点不可用或业务异常，能在最短时间内安全退回原主节点，避免二次故障或数据错乱。

明确回滚触发条件

回滚不是主观判断，而应基于可量化的客观指标：

• 服务级异常：VIP漂移后，健康检查连续3次失败（如HTTP 5xx率＞30%、Nginx upstream timeout超时率突增）
• 数据一致性偏差：数据库主备延迟＞5秒（如KingbaseES的pg_stat_replication中replay_lag）、或日志同步位点停滞
• 业务关键指标恶化：支付成功率下降＞15%、订单创建耗时翻倍、核心接口P99响应＞2s持续2分钟
• 人工确认异常：运维/开发值班人员通过日志、链路追踪（如SkyWalking）确认存在未预期逻辑错误或配置错漏

预置可执行的回滚操作清单

每一步都应有对应命令、脚本或界面入口，禁止临时编写或猜测：

• VRRP类架构（如Nginx+Keepalived）：执行systemctl stop keepalived停备机Keepalived，主机自动抢回VIP；确认ip a显示VIP已回归，curl -I http://VIP返回200
• 数据库流复制（如KingbaseES）：在原主库执行pg_ctl promote -D /data提升为新主，同时在现主库执行pg_rewind重置为备库，再启动流复制
• 云平台主备实例（如华为云RDS）：调用API触发“手动主备倒换”，选择原主实例为新主；或通过控制台“故障恢复”→“回滚至指定时间点”（需提前开启备份与日志保留）
• 所有场景共用动作：回滚后立即执行业务冒烟测试（如登录、查单、下单），并比对回滚前后核心表记录数、校验和（md5sum）

隔离回滚影响范围

避免回滚本身引发雪崩：

• 回滚窗口期关闭自动扩缩容、禁止发布新版本、暂停定时任务（如归档、报表生成）
• 若使用BFD检测，主机回切前先undo bfd session，防止因BFD震荡导致VRRP反复切换
• 数据库回滚后，强制清空应用连接池，避免旧连接仍指向已降级的旧主地址
• 记录完整操作日志（含时间戳、执行人、命令输出），供事后审计与根因分析

定期验证回滚有效性

回滚预案不能只写在文档里：

• 每季度开展一次“无通知回滚演练”：模拟主节点异常，执行切换后再主动触发回滚，全程计时并记录卡点
• 将回滚脚本纳入CI流程，每次变更后自动校验语法与权限（如bash -n、ls -l）
• 在监控系统中为回滚操作设置专属看板，实时展示VIP归属、复制延迟、连接数变化等关键状态