回退脚本必须严格对称主流程、状态可验证、执行可中断且不破坏原环境，核心是精准还原而非重来；需覆盖资源拓扑快照、数据同步水位标记、配置变更基线三大锚点；结构分pre-rollback检查层、rollback执行层、post-rollback验证层；须处理防火墙规则、云资源残留、连接池刷新等细节；并设熔断开关与人工确认点。
设计切换回退脚本不是“做完切换再写个反向操作”那么简单。它必须和主切换流程严格对称、状态可验证、执行可中断，且默认不破坏原环境。核心原则是：**回退不是重来，而是精准还原**。
回退脚本必须覆盖的三大状态锚点
回退能否成功，取决于是否准确捕获并固化三个关键状态：
- 资源拓扑快照：切换前主备节点的IP、主机名、服务端口、云平台资源ID（如AWS Instance ID或Azure VM Name），不能依赖DNS或动态分配值；
-
数据同步水位标记：主库最后已确认提交的事务ID（如PostgreSQL的
pg_current_wal_lsn()、MySQL的SHOW MASTER STATUS输出）、从库已应用的中继日志位置； -
配置变更基线：切换中被修改的配置文件路径+原始哈希值（如
sha256sum /etc/postgresql/15/main/postgresql.conf），而非仅记录“改了什么”。
脚本结构要分层隔离，拒绝单体大脚本
一个健壮的回退脚本应拆为三层，各自独立可验、可跳过：
- Pre-rollback 检查层：验证当前是否处于“已切换但未回退”的中间态（例如检查promote文件是否存在、CDRS中资源是否处于“Failovered”状态），若状态不符则直接退出并报错；
-
Rollback 执行层：按“网络→服务→数据”逆序执行（先恢复DNS/负载均衡指向，再停新主库服务，最后拉起旧主库并重置复制）；每步后调用校验函数（如
curl -s http://old-master:8000/health）； - Post-rollback 验证层：对比回退前后三组锚点——拓扑是否回到初始IP映射、数据库连接是否指向原主库、关键业务表最新记录时间戳是否连续无跳跃。
关键细节：避免常见回退失败陷阱
很多回退失败源于忽略环境残留或权限错位：
- 切换时若启用了临时防火墙规则（如开放9000端口用于健康检查），回退脚本必须显式删除，不能只关服务；
- 云平台场景下，回退需清理切换时创建的临时资源（如AWS中为故障转移启动的EIP、Azure中新建的NSG规则），否则下次演练会因配额超限失败；
- 数据库类回退必须处理连接池残留：脚本需触发应用侧连接池刷新（如发送
SIGHUP给Nginx、调用Spring Boot Actuator的/actuator/refresh），否则旧连接仍打向新主库。
回退脚本必须带“熔断开关”和人工确认点
全自动回退风险极高，脚本应在两个位置强制暂停：
- 执行前显示差异报告（如
diff -u original.conf after-switch.conf），要求输入YES-CONFIRM继续； - 数据层操作（如
pg_rewind或RESET MASTER）前，输出当前WAL位置与原始备份点偏移量，超阈值（如>10MB）则终止并告警。
回退脚本的价值不在“能跑通”，而在“敢在生产里跑”。它必须像手术刀一样精确，每一步都留痕、可逆、可审计。
