MySQL GTID 迁移怎样避免跳过事务

MySQL GTID 迁移避免跳过事务，核心是让目标的数据快照与声明的 GTID 水位对应，再确认新源能提供目标缺少的事务。GTID 自动定位会依据目标报告的事务集合判断哪些事务不用再发送；如果只把事务标识补进去而没有对应数据，复制可能正常运行，却留下数据缺口。

下面做一个只读的集合比较小练习，适用于理解单源、完整数据范围的迁移。以 MySQL 8.4 文档为基线，SQL 未执行，不是可以直接切换生产拓扑的通用脚本。多源、过滤复制、带标签 GTID 或跨版本迁移，需要额外评估自己的配置与支持范围。

官方说明：https://dev.mysql.com/doc/refman/8.4/en/replication-gtids-auto-positioning.html

先定义一个可检查的迁移目标

目标不是“复制线程变绿”，而是目标拥有指定数据范围内的基础快照，并能够连续取得备份水位之后的事务。要保存来源实例、备份时点、数据范围、备份工具和版本、对应 GTID 集合以及后续日志保留计划。不要只保存一个最大的事务序号：不同来源 UUID 有独立区间，集合还可能有空洞。

为练习定义三个集合：S 是候选新源记录的已执行集合，R 是目标记录的已执行集合，P 是新源已清理、不再保留在其 binlog 中的集合。S 减 R 表示目标尚未标记执行的源事务；R 减 S 表示目标额外记录的事务；P 减 R 可以暴露目标缺少且新源已清理的事务。它们是元数据判断，不是内容校验结果。

把数据快照和事务水位成对准备

gtid_executed 表示实例记录为已执行的 GTID；gtid_purged 表示已执行但不再存在于本机 binlog 中的部分。二者都不能直接证明表内容相同。目标曾经跳过事务、过滤数据或在关闭会话 binlog 时修改数据，都可能造成“集合看起来够了，数据却不够”的情况。

自动定位握手还会考虑已经接收到的事务集合，不能把 received 当成已经应用。目标可能已收到 relay log，但应用线程尚未完成；切换前应看执行水位和应用错误，不能只看接收进度。

-- 在每个参与实例分别采集并标注来源和时间，结果不要混成同一实例。
SELECT @@GLOBAL.server_uuid AS instance_uuid,
       @@GLOBAL.gtid_mode AS gtid_mode,
       @@GLOBAL.gtid_executed AS executed_set,
       @@GLOBAL.gtid_purged AS purged_set;

-- 在目标查看接收与应用状态；多通道时逐个确认对应通道。
SHOW REPLICA STATUS;

备份的 GTID 水位必须来自与数据一致的备份流程，不能在备份结束后随便查询一次新源水位并写进目标。源继续写入时，这个后查水位可能包含快照没有的数据。备份过程中 DDL、非事务表和工具行为也要按工具文档处理，不应把一致性快照等同于任何类型数据都自动完整。

mysqldump 的部分库表备份尤其需要注意：其 GTID 声明可能覆盖实例全部已执行事务，包括没有导出的数据库或表。将局部数据导入一个要承接完整复制范围的目标，却继承完整水位，可能让缺失的历史被当成已完成。不能把 set-gtid-purged=OFF 当成通用修复，它同样要求另行正确管理恢复水位。官方工具说明：https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html。

用一个集合比较小例子发现缺口

下面使用虚构 UUID：源已执行 1–120，目标已执行 1–100，源已清理 1–110。查询只计算字符串集合，不会修改实例 GTID 状态。

WITH sample_sets AS (
    -- 虚构教学集合，不能将这些字符串写入生产实例元数据。
    SELECT
        'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-120' AS source_set,
        'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-100' AS target_set,
        'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-110' AS purged_set
)
SELECT
    -- 目标缺少哪些源事务标识。
    GTID_SUBTRACT(source_set, target_set) AS missing_on_target,
    -- 目标是否记录了候选源没有的额外事务。
    GTID_SUBTRACT(target_set, source_set) AS extra_on_target,
    -- 目标缺少且源已清理的标识，需查可用备份或其他日志来源。
    GTID_SUBTRACT(purged_set, target_set) AS missing_but_purged,
    GTID_SUBSET(purged_set, target_set) AS purged_already_covered
FROM sample_sets;

按集合规则推导，missing_on_target 是 101–120，extra_on_target 为空字符串，missing_but_purged 是 101–110，最后的子集判断为 0。这是预期推导，不是实测输出。源可能还能发送 111–120，但 101–110 的历史已不在它的 binlog 中，不能宣布迁移可直接追平。

真实比较应使用有来源、时间和通道记录的采样值。S 减 R 非空可能只是正常复制延迟；P 减 R 非空是更明确的日志缺口线索。R 减 S 非空则要调查目标本地写入、其他来源或候选源缺少历史，不能直接删除额外集合。函数文档：https://dev.mysql.com/doc/refman/8.4/en/gtid-functions.html。

自动定位不能修复丢失的数据

启用 SOURCE_AUTO_POSITION 是让复制根据 GTID 协商位置，不是让复制补建任意基础数据。如果目标把未恢复的数据对应 GTID 标记为已执行，源会按目标的声明跳过它们；接收和应用状态正常也可能掩盖这个问题。

若源已清理目标需要的事务，官方文档明确说明自动定位无法自动恢复该缺口。应寻找仍有完整历史的受控来源、按完整恢复方案补齐，或重做匹配快照；不能关闭自动定位并从更晚文件位置接入，假装历史已经不存在。也不要注入空事务或扩大 gtid_purged 来消除错误：这只可能改变标记，并不会恢复原事务效果。

所有修改 GTID 状态、重置复制信息、清理 binlog 或切换写入的操作都应由实际迁移方案控制。本文只提供比较练习，不提供清空状态或“跳错继续”的命令，以免将诊断线索变成数据损失。

接入与切换分别设置放行条件

接入前确认：基础数据和水位匹配、GTID 配置及版本兼容、复制过滤范围一致、身份和连接安全配置正确、新源仍有必要日志。复制接入后继续观察接收与应用错误，而不是仅凭线程运行就放行。日志保留期应覆盖备份、传输、恢复、追平及可能返工的时间。

最终切换需要一个明确的写入屏障：阻止旧写入入口并处理在途事务，取得稳定的最终源水位，再确认目标执行集合覆盖该水位。覆盖只是必要条件，还应检查数据范围、业务不变量和历史是否存在跳过或过滤。不能在源持续写入时比较两次不同时间的集合，然后把差异为空当作永久追平。

新源开始接受写入后，旧源不能无条件重新变成主库。需要评估新事务的反向同步、版本兼容、数据合并与单写约束。保留旧备份和日志是恢复准备，不等于回退按钮随时安全。

GTID 集合相同还可能数据不同吗？

可能。过滤、人为跳过、未记录的数据变更或不匹配的恢复都能破坏集合与数据效果的对应关系。

只迁移一个数据库怎么办？

先明确未来复制的数据范围，并评估部分备份携带的实例级 GTID 声明。不能按完整实例恢复的思路直接套用。

发现日志缺口能继续切换吗？

在没有可靠恢复证据前不应放行。先解决缺失历史与基础数据问题，再推进追平和写入切换。避免跳过事务的关键，是诚实保留缺口，而不是让状态字段看起来正常。