GTID恢复不能直接用--skip-gtid，因该参数根本不存在；必须停库、清空GTID状态、关闭gtid_mode后，才能基于binlog position安全恢复。
GTID恢复为什么不能直接用 --skip-gtid
MySQL 5.6+ 启用 GTID 后，gtid_mode=ON 时，--skip-gtid 并不是一个合法的启动参数——它根本不存在。你看到的可能是误传、混淆了 --gtid-mode=OFF 或某些备份工具（如 mydumper）的私有选项。真实场景中，想绕过 GTID 约束做基于位置的恢复，必须先停库、临时关闭 GTID，再以传统 binlog pos 方式启动复制或导入。
如何安全地从 GTID 模式切回 pos 恢复模式
核心是「停库 → 清空 GTID 状态 → 关闭 GTID → 重放 binlog 到指定 pos」。关键步骤如下：
- 确保主从已停止写入，且所有从库已追上主库（
Seconds_Behind_Master = 0） - 执行
SET GLOBAL gtid_mode = OFF_PERMISSIVE;，再SET GLOBAL gtid_mode = OFF;（需满足enforce_gtid_consistency = ON且无未提交 GTID 事务） - 重启 mysqld，配置文件中显式设置：
gtid_mode = OFF、enforce_gtid_consistency = OFF（否则启动失败） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v定位目标 pos（不是 GTID，而是at 123456这类偏移量） - 导入时加
--stop-position=123456，或在CHANGE MASTER TO中用MASTER_LOG_FILE和MASTER_LOG_POS
RESET MASTER 会清空 GTID_EXECUTED，但别乱用
执行 RESET MASTER 后，gtid_executed 变为空集，gtid_purged 也被重置为 ''。这看似“干净”，但后果严重：
- 如果从库还在用 GTID 复制，它会因找不到
gtid_purged对应的事务而报错Could not execute Write_rows event on table... Error_code: 1594 - 即使你打算切回 pos 恢复，也必须确保所有节点同步停机，否则 binlog 文件和 pos 映射关系将错乱
- 真正需要的是
RESET MASTER+FLUSH LOGS+ 手动删掉旧 binlog 文件（保留新生成的），而非仅靠命令“重置”
恢复后重新启用 GTID 的风险点
恢复完成、数据校验无误后，若要重新开启 GTID，必须严格满足三个条件：
- 所有实例（主+从）都已停写，且 binlog 中不含任何 GTID 事务（即全为 pos 模式写入）
- 先设
enforce_gtid_consistency = ON，再依次执行：SET GLOBAL gtid_mode = OFF_PERMISSIVE;→SET GLOBAL gtid_mode = ON_PERMISSIVE;→SET GLOBAL gtid_mode = ON; - 重启后检查
SELECT @@gtid_executed;是否与预期一致；若从库报Missing GTID set in Retrieved_Gtid_Set，说明主库 binlog 里混入了 GTID 事务，恢复过程已污染
GTID 和 pos 是两种互斥的坐标体系，强行混用只会让 MySQL 在解析时失去事务边界判断能力——最常被忽略的是：你以为跳过了某个 GTID，其实只是跳过了它的事件头，后续行事件仍会被应用。
