适用范围与前提
本文是「MySQL 主从高可用」场景的计划切换检查单，面向 MySQL 8.4、单写源库与 GTID 复制。它不适用于源库已经不可访问的紧急故障转移，也不替代现有高可用组件的操作手册。先明确变更窗口、允许中断、数据丢失目标、操作负责人、应用入口和回退决策点；全文为待环境验证参考。
核对拓扑和候选副本
逐个确认实例身份、复制方向、版本兼容性、复制过滤规则及备份恢复可用性。候选副本应具备承接业务的容量、账号、网络策略和日志配置。检查自动切换系统是否会与人工操作竞争，按既定运维流程进入受控状态。
SELECT @@server_uuid, @@version, @@global.gtid_mode,
@@global.read_only, @@global.super_read_only;
SHOW REPLICA STATUS\G查询在候选副本执行。保存结果后确认复制没有错误、候选不是延迟副本，并核实其他副本能连接候选。不要只依据「延迟为 0」选择新主。
建立明确的写入边界
在切换流程中先暂停应用写入并排空进行中的写事务，再按环境既定方式隔离旧主的写权限和入口。仅改变代理地址不足以隔离仍持有旧连接的客户端。只读设置、应用连接池和网络入口应共同验证，不以一次配置返回成功代替实际检查。
确认写入冻结后，在旧主读取 @@GLOBAL.gtid_executed，把这个不可再增长的集合记录为本次切换边界，同时保存冻结时间和应用侧证据。
验证候选已覆盖边界
在候选执行下面的只读集合判断。字符串是占位符，必须替换成刚记录的完整 GTID 集合：
SELECT GTID_SUBSET('REPLACE_WITH_FROZEN_SOURCE_GTID_SET',
@@GLOBAL.gtid_executed) AS boundary_applied;
SELECT GTID_SUBTRACT(@@GLOBAL.gtid_executed,
'REPLACE_WITH_FROZEN_SOURCE_GTID_SET') AS extra_gtids;第一项为 1 表示候选执行集合覆盖边界；第二项若非空，应查明额外事务来源。集合相符不等于已证明所有表内容一致，还须排除过滤规则、历史跳过事务和非复制写入，并完成所需业务数据核验。GTID 函数的定义见文末官方文档。
切换顺序与业务验收
通过全部检查后，按已验证的切换工具或操作单完成提升候选、重定向副本和应用入口。重新开放写入前再次确认唯一写主与旧主隔离。用独立测试对象进行经授权的写后读验证，记录请求标识；从应用连接确认实际服务实例，检查错误率、连接重建和关键业务路径。
随后观察下游副本是否跟随新主、复制进度是否推进、备份与监控是否指向正确角色。验收记录应填写实测中断与数据核验结果，不能预先写成「零丢失、零中断」。
切换后还应检查定时任务、离线客户端和只读服务是否仍使用旧地址。为长连接保留足够观察时间，将遗漏入口加入连接清单，避免前台验证通过而后台任务继续访问旧拓扑。
回退边界与停止条件
候选未开始接收新写入前，可在确认旧主仍为权威数据源后按原入口恢复。新主已经接收写入后，直接把流量切回旧主会造成数据分歧，应冻结变更，先核对两侧事务并建立反向同步或重新初始化方案。若写入无法可靠隔离、GTID 差异无法解释或候选资源不足，停止切换并保留当前证据。