切换前检查清单是什么
切换（switchover 或 failover）失败大多不是数据库本身的问题，而是漏掉了周边环节：数据没追平、应用还在往旧主写、代理层没切、回退路径没定。清单的作用是让每个步骤都可核对、有负责人：任何一项未通过就判定 No-Go，推迟切换而不是带着风险硬上。
基本信息
| 适用对象 | 主从切换、计划内维护、故障提升 |
|---|---|
| 判定方式 | 逐项打钩，任一未过即 No-Go |
| 数据前提 | GTID 环境下新主已执行集合 ⊇ 旧主最终集合 |
| 写保护 | 旧主 read_only / super_read_only 已开，业务停写确认 |
| 周边环节 | 应用连接串、VIP、代理层、DNS 均可切换 |
| 观察窗口 | 明确盯盘人、观察时长与回退触发条件 |
切换前检查清单
- 新主 Executed_Gtid_Set 已覆盖旧主最终集合（GTID 环境）
- 旧主已开 read_only，业务写入确认停止（应用日志无写入失败刷屏）
- 新主 super_read_only 已关闭，写入自测通过
- 应用连接串与代理配置已准备，可一键切换或已验证切换脚本
- 回退路径明确：旧主可重新挂回新主作为从库，命令已备好
- 观察窗口与责任人确认：谁盯盘、观察多久、什么条件触发回退
打钩验证查询
打钩验证查询
-- 旧主最终集合（切之前记录，作为基准）
SELECT @@GLOBAL.gtid_executed;
-- 新主追平确认：返回 1 表示已执行到指定集合
SELECT @@GLOBAL.gtid_executed;
SELECT WAIT_FOR_EXECUTED_GTID_SET('旧主最终集', 60);
-- 新旧主写状态核对
SELECT @@GLOBAL.read_only, @@GLOBAL.super_read_only;
-- 复制链路是否仍在同步
SHOW REPLICA STATUS\G切换后的验证与旧主回挂
切换后的验证与旧主回挂
# 1) 新主写入自测
mysql -h new-master -e "CREATE TABLE _smoke(id INT PRIMARY KEY); INSERT INTO _smoke VALUES (1); DROP TABLE _smoke;"
# 2) 应用探针与错误率确认恢复
curl -s -o /dev/null -w '%{http_code}\n' https://app.example.com/health
# 3) 旧主以从库身份挂回新主（回退前置动作）
mysql -e "CHANGE REPLICATION SOURCE TO SOURCE_HOST='new-master', SOURCE_AUTO_POSITION=1; START REPLICA;"检查项与遗漏后果
| 检查项 | 验证方式 | 遗漏后果 |
|---|---|---|
| 数据已追平 | GTID 集合比对 / 位点比对 | 切换后丢事务，业务数据出现缺口 |
| 业务已停写 | 应用日志与连接状态 | 双写造成新旧主数据冲突 |
| 写保护已开 | read_only / super_read_only 查询 | 旧主被误写，回挂时冲突 |
| 代理与应用可切 | 切换脚本试运行 | 切了主库但业务仍连旧地址 |
| 回退路径明确 | 旧主回挂命令演练 | 出现问题无法回退，只能硬扛 |
把清单固化进发布系统或工单模板：切换从「即兴发挥」变成「标准作业」，同时天然留下每步的时间戳，复盘时能准确判断是哪一步拖慢了整体。
切换窗口不要选在业务高峰：切换过程中不可避免会有秒级到分钟级的中断，高峰期的中断会被放大成大面积故障，且回退操作本身也会影响业务。