MySQL GTID 复制切换前的执行状态核对

MySQL 复制切换前，最可靠的判断不是单看延迟秒数，而是确认候选副本的 Executed_Gtid_Set 已覆盖原主库最后一次可接受写入对应的 GTID 集合。实际核对应同时看三件事：写入是否已经冻结、复制接收与应用是否都没有错误、候选副本是否拥有完整且可解释的执行历史。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

先冻结写入，再保存切换前状态

先在业务入口停止写请求，或者把应用切到维护/排队模式；然后等待正在执行的事务结束。数据库侧可以暂时打开只读保护，但这一步的目标是形成一个明确的切换边界，不是用参数掩盖仍在写入的业务连接。

-- 记录两台服务器的身份与 GTID 能力，输出应分别保存
SELECT @@server_uuid AS server_uuid,
       @@GLOBAL.gtid_mode AS gtid_mode,
       @@GLOBAL.enforce_gtid_consistency AS gtid_consistency,
       @@GLOBAL.read_only AS read_only,
       @@GLOBAL.super_read_only AS super_read_only;

-- 保存执行历史和已经从二进制日志中清理的历史
SELECT @@GLOBAL.gtid_executed AS executed_gtid_set,
       @@GLOBAL.gtid_purged AS purged_gtid_set;

gtid_executed 表示服务器已经执行过的 GTID 集合；gtid_purged 是其中已经不在当前二进制日志里的部分。切换前不要执行 RESET BINARY LOGS AND GTIDS，它会清空 GTID 执行历史和二进制日志，不能拿来“整理”核对结果。

把收到过和已经应用分开核对

在候选副本执行 SHOW REPLICA STATUS\G，重点保存下面几组字段。Retrieved_Gtid_Set 只说明事务已经进入或曾经进入 relay log；真正用于判断数据是否跟上的是 Executed_Gtid_Set。Auto_Position=1 则说明该通道使用 GTID 自动定位。

-- 在候选副本保存复制线程与 GTID 状态
SHOW REPLICA STATUS\G

-- 用查询结果中的字段做人工核对，示例值仅表示字段关系
SELECT
  'Replica_IO_Running=Yes' AS io_check,
  'Replica_SQL_Running=Yes' AS sql_check,
  'Auto_Position=1' AS auto_position_check,
  'Last_IO_Error 与 Last_SQL_Error 均为空' AS error_check;

用 GTID 集合证明候选副本没有漏事务

把原主库在冻结点记录的集合记为 @source_executed，把候选副本的 Executed_Gtid_Set 记为 @candidate_executed。实际操作可以把两段值作为字符串代入下面的判断。第一项应为 1；第二项最好为空，若有结果就代表候选副本还缺少这些主库已经执行的事务。

-- 将两台服务器在同一冻结点保存的 GTID 集合填入变量
SET @source_executed = 'SOURCE_UUID:1-1200';
SET @candidate_executed = 'SOURCE_UUID:1-1200';

-- 判断候选副本是否覆盖主库，并列出主库缺失的事务
SELECT GTID_SUBSET(@source_executed, @candidate_executed) AS source_is_covered,
       GTID_SUBTRACT(@source_executed, @candidate_executed) AS missing_on_candidate;

-- 只比较接收集合与执行集合，定位仍在应用链路中的事务
SELECT GTID_SUBTRACT(@candidate_retrieved, @candidate_executed)
       AS received_but_not_executed;

多线程副本在应用事务时可能暂时出现 GTID 区间间隙，干净地执行 STOP REPLICA 会等待正在处理的事务收敛；如果是异常终止，间隙可能保留。因此不能把“集合字符串看起来接近”当成通过条件，必须保留函数结果和线程状态。

提升前的边界与回退清单

最后再检查候选副本的复制过滤规则、Source_UUID、通道名称、延迟策略以及最近错误时间。若使用了库表过滤，GTID 覆盖只能证明事务标识已到达，不能自动证明所有业务表都符合切换目标；这类环境还要按业务库做独立一致性检查。

确认快照已落盘后，才进入提升动作。典型顺序是停止候选副本复制、保留旧主库的只读状态、解除候选副本的只读保护，再让其他副本使用自动定位回连：

-- 候选副本已通过集合覆盖检查后，停止复制通道
STOP REPLICA;

-- 解除新主库的写保护；先确认应用流量已经切换
SET GLOBAL super_read_only = OFF;
SET GLOBAL read_only = OFF;

-- 其他副本改指向新主库，使用 GTID 自动定位
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'new-primary.example',
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

这里的关键不是某条命令本身，而是每个状态变化都有对应的记录：冻结时间、主库执行集合、候选副本执行集合、缺失集合、线程错误和回连结果。任何一项无法解释，都应继续保持只读并回到排查，而不是靠重启或清空 GTID 历史“修复”。

常见问题

Seconds_Behind_Source 为 0 就能直接切换吗？

不能。它只能反映某一时刻的时间差，不能证明主库最后事务已经在候选副本提交。应优先比较冻结点的 GTID 集合。

Retrieved_Gtid_Set 比 Executed_Gtid_Set 大正常吗？

可以暂时正常，通常表示事务已经接收但还在等待应用。切换前应等待差集为空，并同时确认 SQL 线程无错误。

为什么不直接修改 mysql.gtid_executed 表？

它是 MySQL 内部系统表，GTID 状态由服务器维护。需要记录恢复历史时使用官方支持的 GTID 配置或备份流程，不直接改表。