MySQL 复制状态中 Retrieved_Gtid_Set 如何辅助定位缺口

看到副本的 Retrieved_Gtid_Set 比源库的 GTID 集少，不能马上断定“事务丢了”。这个字段表示副本已经收到、并存在或曾存在于 relay log 中的事务；真正写入副本本地 binlog 的进度要看 Executed_Gtid_Set。排查时把两个差集分开算，才能判断问题卡在接收链路还是 SQL 应用线程。

先把 Retrieved 和 Executed 放在同一张状态表里

在副本上执行 SHOW REPLICA STATUS，优先保存同一个通道的完整输出。这个语句是非阻塞的，适合监控采样，但它可能在复制线程变化的瞬间返回稍旧的状态，所以不要只凭一次结果下结论。

-- 读取默认复制通道，重点记录接收、应用和错误字段
SHOW REPLICA STATUS\G;

-- 有多通道时指定通道，避免把不同来源混在一起
SHOW REPLICA STATUS FOR CHANNEL 'orders_channel'\G;

重点字段可以这样理解：

先算副本内部差集，判断是否只是应用积压

假设一次采样得到：

-- 以下是脱敏后的示意输出，不代表某台真实服务器
Retrieved_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-120
Executed_Gtid_Set:  3e11fa47-71ca-11e1-9e33-c80aa9429562:1-105

这时先在副本上计算“已收到但未执行”的集合：

-- 计算 relay log 中已收到、但本地尚未执行的 GTID
SELECT GTID_SUBTRACT(
  '3e11fa47-71ca-11e1-9e33-c80aa9429562:1-120',
  '3e11fa47-71ca-11e1-9e33-c80aa9429562:1-105'
) AS received_not_executed;

结果是 ...:106-120，说明接收线程已经把这段事务拿到 relay log，应用线程还没追上。此时优先看 Replica_SQL_Running、Replica_SQL_Running_State、Last_SQL_Error 和并行复制是否出现等待，不要把它当成网络丢包。

再与源端集合比较，定位真正的接收缺口

如果要判断副本是否还没有收到源端已经执行的事务，需要从源库取得同一时刻附近的 Executed_Gtid_Set，再与副本的 Retrieved_Gtid_Set 比较。示例中源端已经到 140，而副本只收到 120：

-- 在源端 SHOW BINARY LOG STATUS 中读取 Executed_Gtid_Set 后代入
-- 差集表示源端已执行、但副本接收集合里暂时没有的 GTID
SELECT GTID_SUBTRACT(
  '3e11fa47-71ca-11e1-9e33-c80aa9429562:1-140',
  '3e11fa47-71ca-11e1-9e33-c80aa9429562:1-120'
) AS source_not_retrieved;

返回 ...:121-140，才应沿着接收链路检查连接、认证、I/O 线程和源端是否仍在产生事务。这个差集和上一节的 106-120 不是同一个问题：前者是“还没收到”，后者是“收到了但还没应用”。

四个边界要在结论里写清楚

• relay log 被清理：RESET REPLICA、更换源配置或 relay log 恢复过程可能清空 Retrieved 集；清空后的字段不能用来还原完整历史。
• 多通道：按 FOR CHANNEL 分开采样。不同来源的 GTID 集混合后，差集很容易被误读。
• 复制过滤：副本可能按库表过滤事件。差集说明集合差异，不自动说明业务数据一定缺失，要结合过滤规则和目标库范围。
• 采样时间：源端和副本输出不是原子快照。连续采样两三次，并记录时间、通道和错误字段，比拿两份相隔很久的输出直接相减可靠。

最后可以把检查流程固定成一句话：先看副本内部的 Retrieved - Executed，再看源端的 Executed - 副本 Retrieved，最后用线程状态与错误字段验证。GTID_SUBTRACT() 返回空，只代表给定两组集合没有发现差异，不能替代数据一致性校验。

常见问题

Retrieved_Gtid_Set 为空是不是复制坏了？

不一定。GTID 未启用、通道尚未收到事务、relay log 被清空，都会让它为空，应同时查看 GTID_MODE、线程状态和错误字段。

Retrieved_Gtid_Set 等于 Executed_Gtid_Set 就代表追平了吗？

只代表副本已收到的集合都已执行。若源端在此后产生了新事务，仍需用源端 Executed 集合再比较一次。

为什么不能只看 Seconds_Behind_Source？

它反映的是时间维度的延迟，不能告诉你具体缺哪些 GTID；事务时间戳、并行应用和暂停状态也可能让时间值与集合差异不一致。

差集非空时可以直接跳过事务吗？

不建议。先确认是传输问题、应用错误、过滤规则还是人为暂停，再按复制拓扑和数据恢复方案处理；差集本身不是跳过事务的授权。