set gtid_purged失败或引发数据断裂，因从库未彻底清理：reset slave all不删relay-bin.文件，残留日志可能重放导致gtid冲突；赋值前必须stop slave、手动删除relay-log.index及所有relay-bin.文件，并确保gtid_executed为空、值精确匹配主库@@global.gtid_executed。
为什么 SET GTID_PURGED 会失败或引发数据断裂
执行 SET GTID_PURGED 前，从库状态必须“干净”：既不能残留旧 relay log 文件，也不能存在未清理的内存位点。只运行 RESET SLAVE ALL 不够——它清除了复制元数据，但 relay-log.index 和实际的 relay-bin.* 文件还在磁盘上，MySQL 启动时可能自动加载并尝试重放，导致 GTID 冲突或跳过关键事务。
常见错误现象包括：Could not execute Write_rows event on table（错误码 1594）、Missing GTID set in Retrieved_Gtid_Set、SQL 线程卡在 Waiting for executed GTID set to be updated。
- 必须先
STOP SLAVE，再手动删除所有relay-bin.*和relay-log.index - 确认
SHOW SLAVE STATUS\G中Relay_Log_File和Relay_Master_Log_File为空 -
SET GTID_PURGED只能执行一次，且必须在gtid_mode = ON且enforce_gtid_consistency = ON下进行 - 赋值内容必须是主库当前
@@global.gtid_executed的精确字符串（含 UUID 段、冒号、范围，空格也不能多一个）
如何安全获取并验证主库的 GTID_EXECUTED 值
别直接抄 SHOW MASTER STATUS 里的 Executed_Gtid_Set——它可能已被 PURGE 或部分截断。真正可信的是 SELECT @@global.gtid_executed，且需在主库写入暂停后立即执行（避免新事务插入干扰）。
若主库已切走、不可达，或你手头只有备份文件，就打开 mysqldump 输出的 SQL 文件，找第一处 SET @@GLOBAL.GTID_PURGED=... 行。该值来自备份时刻主库的 gtid_executed，可用于新建从库；但它**不能直接用于修复已有从库**，除非你确认该从库自备份后没执行过任何事务。
- 执行前先检查主库 binlog 是否完整：
SHOW BINARY LOGS确认所需 GTID 范围仍在日志中 - 若
SELECT @@global.gtid_executed返回空，说明主库刚初始化或被RESET MASTER清过——此时无法用 GTID 恢复，只能切回 binlog position 模式 - 跨 server_uuid 的 GTID（如从库曾连过测试主库）必须剔除，否则
SET GTID_PURGED会报错
误操作后从库 GTID 缺失，但主库仍可用的快速路径
这不是“修”，而是“重建同步起点”。核心是让从库放弃原有 GTID 追踪，以主库当前状态为唯一权威源重新对齐。
- 在从库执行：
STOP SLAVE; RESET SLAVE ALL;，然后手动删掉relay-bin.*和relay-log.index - 查主库：
SELECT @@global.gtid_executed;，记下完整字符串 - 在从库执行：
SET @@global.gtid_purged = 'xxx';（注意：不是gtid_executed） - 再执行：
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;，然后START SLAVE; - 立刻检查：
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set是否开始增长，且两者差值稳定缩小
如果 START SLAVE 报错 error 1236，说明主库 binlog 已丢失从库需要的部分——此时别硬等，直接走 xtrabackup 全量重建从库更可靠。
GTID 缺失但主库也不可用时的兜底方案
当主库宕机、binlog 损毁，或你只有旧备份 + 增量 binlog 文件时，SET GTID_PURGED 失效，唯一可行路径是退回到传统 position 恢复模式。这要求你停掉所有节点，清除 GTID 状态，再按 pos 重放。
- 停所有 MySQL 实例，修改配置文件：设
gtid_mode = OFF、enforce_gtid_consistency = OFF - 启动从库（此时无 GTID），用
mysqlbinlog --base64-output=DECODE-ROWS -v定位误操作前最后一个at位置 - 用
--stop-position导入 binlog，或CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=123456 - 恢复完成后如需重开 GTID，必须确保所有实例 binlog 全为 pos 模式写入，再按
OFF_PERMISSIVE → ON_PERMISSIVE → ON三步切换
最容易被忽略的一点：GTID 和 binlog position 是两套互斥坐标系统，混用不会“取长补短”，只会让 MySQL 在解析时彻底失去事务边界——一旦开始用 pos 恢复，就别回头再塞 GTID。
