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 STATUS\G 中 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 或跳过了事务，整个自动定位逻辑就失去依据。
