SQL GTID 复制的 executed_gtid_set 与 auto-position 机制实践

mysql 8.0中executed_gtid_set不连续会导致auto-position复制启动失败，因gtid差集无法确定同步起点；需reset slave all后重新配置auto_position=1，并确保gtid_mode与enforce_gtid_consistency均为on。

MySQL 8.0 中 executed_gtid_set 不连续导致从库无法启动 auto-position

当从库的 executed_gtid_set 出现空洞（gap），比如跳过了某个 GTID 事务，START SLAVE 会直接报错 Error 3021 (HY000): this operation cannot be performed with a running slave 或更常见的 ERROR 1794 (HY000): The slave is not configured or failed to initialize properly —— 实际上是 GTID 自动定位失败了。

根本原因：auto-position 启用后，从库不再依赖 CHANGE MASTER TO ... MASTER_LOG_FILE/MASTER_LOG_POS，而是靠 executed_gtid_set 和主库的 gtid_executed 做差集，算出需要拉取的事务范围。一旦本地 executed_gtid_set 缺失中间 GTID，MySQL 就无法确定“从哪开始追”，干脆拒绝启动复制。

• 检查缺口：在从库执行 select * FROM performance_schema.replication_applier_status_by_coordinator; 看 LAST_PROCESSED_TRANSACTION 是否断层；或对比 SELECT @@global.gtid_executed; 和主库的输出
• 修复方式不是“补 GTID”，而是重置：先 STOP SLAVE;，再 RESET SLAVE ALL;（清空 relay log、master info、gtid_purged 等），然后用 CHANGE MASTER TO ... AUTO_POSITION = 1; 重新配置
• 注意 RESET SLAVE ALL 会清除 gtid_purged，如果从库曾执行过 SET GLOBAL gtid_purged = ...，重置后需手动补回，否则主库可能拒绝发送已 purge 的事务

启用 auto-position 前必须确保主从 gtid_mode = ON 且 enforce_gtid_consistency = ON

这两个参数不是“建议开启”，而是 auto-position 的硬性前提。只要其中任一为 OFF，即使你在 CHANGE MASTER TO 里写了 AUTO_POSITION = 1，MySQL 也会静默忽略，并退回到基于 binlog 文件名+位置的传统复制模式。

常见误操作：只改了主库，忘了从库；或者用 SET GLOBAL 临时修改，但没写进 my.cnf，重启后失效，导致某次故障恢复后复制突然“变慢”或“跳事务”——其实是退化成了 file/pos 模式，而 dba 还以为是 GTID 在工作。

• 确认命令：在主从两端都执行 SELECT @@gtid_mode, @@enforce_gtid_consistency;，结果必须是 ON, ON
• 动态设置无效：这两个变量不支持运行时修改（MySQL 8.0.26 之前会报错 ERROR 1238 (HY000): Variable 'gtid_mode' is a read only variable），必须改配置文件 + 重启
• 从库若曾用 file/pos 模式运行过，切到 GTID 前需先 STOP SLAVE;，再 RESET SLAVE; 清理旧位点，否则 AUTO_POSITION = 1 仍可能被绕过

gtid_purged 被意外覆盖导致主库拒绝提供 binlog

从库执行 RESET SLAVE ALL 或导入备份时手动设置了 gtid_purged，但值比主库当前的 gtid_executed 还大，主库就会在握手阶段直接断连，错误日志里出现 The slave tried to set gtid_purged to a value greater than the current gtid_executed on the master。

本质是主库的自我保护：它不允许从库声称“我已经执行了你还没生成的事务”。这个判断发生在 CHANGE MASTER TO ... AUTO_POSITION = 1 执行时，而不是启动复制后。

• 安全做法：从库的 gtid_purged 应 ≤ 主库的 gtid_executed；最稳妥是让它等于主库 gtid_executed 的子集（比如用备份时记录的 Executed_Gtid_Set）
• 查主库当前值：SELECT @@global.gtid_executed;；查从库已 purge 的：SELECT @@global.gtid_purged;
• 若已出错，不能删主库 binlog 来迁就从库；只能修正从库 gtid_purged：停从库 → SET GLOBAL gtid_purged = 'xxx-yyy:1-100';（填主库实际值的子集）→ 再 CHANGE MASTER TO ... AUTO_POSITION = 1;

mysqldump 备份恢复后从库无法 auto-position 同步

用 mysqldump --single-transaction --set-gtid-purged=ON 导出的 SQL 文件，默认会在开头插入类似 SET @@GLOBAL.GTID_PURGED='xxx:1-100'; 的语句。如果这个值和你实际要恢复到的主库状态不匹配（比如主库已推进到 xxx:1-150），恢复后从库的 gtid_purged 就会偏小，导致 auto-position 计算出错，复制卡在“等待第一个事务”状态，SHOW SLAVE STATUSG 中 Retrieved_Gtid_Set 为空，Exec_Master_Log_Pos 停在 4。

这不是数据问题，是元数据错配。很多 DBA 反复 START SLAVE 却无反应，就是因为没意识到 GTID 元信息已经锁死了同步起点。

• 导出时加 --set-gtid-purged=OFF 可跳过注入，但恢复后必须手动 SET GLOBAL gtid_purged = '...';（用主库当前值）
• 更推荐用 --set-gtid-purged=auto（默认），它会自动读取源实例的 gtid_executed 并写入；但前提是 dump 时连接的是你要对齐的那个主库
• 恢复后立刻验证：SELECT @@global.gtid_purged; 必须包含主库 gtid_executed 的前缀，且不能有超出部分

GTID 复制里真正难的不是配置开关，而是所有节点的 GTID 集合必须构成一个可推导的、无歧义的偏序关系；一旦某个环节人为干预了 gtid_purged 或跳过了事务，整个自动定位逻辑就失去依据。