GTID模式本身不提供备份功能，但可实现精准事务边界恢复；前提是备份时必须手动记录gtid_executed快照（如执行SELECT @@global.gtid_executed），且主库binlog未被PURGE，否则无法定位事务起点。
GTID模式本身不提供备份功能，但它让备份后的恢复能精准定位到事务边界——前提是备份时记录了gtid_executed快照，且主库binlog未被PURGE。
备份时必须抓取gtid_executed快照
mysqldump或XtraBackup本身不会自动保存GTID位置，你得手动在备份前执行：SELECT @@global.gtid_executed; 并把结果写入备份文件头或独立元数据文件。否则恢复时无法知道“这个备份包含哪些GTID”。
- mysqldump配合
--master-data=2只记录File/Position，对GTID无效；必须额外加--set-gtid-purged=ON（默认值），它会把当前gtid_executed写进dump头部 - XtraBackup 8.0+支持
--dump-gtid参数，生成xtrabackup_binlog_info时自动包含GTID_EXECUTED字段；旧版本需手动执行SHOW MASTER STATUS和SELECT @@global.gtid_executed并存档 - 如果备份期间有新事务提交，
gtid_executed会变化——所以务必在备份开始前立即获取，不能等备份结束再查
恢复后必须用SET GTID_NEXT跳过已存在GTID
直接mysql < backup.sql会导致“Duplicate entry for key 'PRIMARY'”或“GTID already executed”错误，因为dump里含SET @@SESSION.GTID_NEXT语句，而目标实例可能已有相同GTID。
- 若目标实例是全新空库，可放心导入；但如果是追加恢复或重建从库，必须先执行
RESET MASTER清空gtid_executed和gtid_purged，否则GTID冲突直接拒绝启动复制 - 若目标实例已有部分数据，应先查
SELECT @@global.gtid_executed;，再对比备份里的GTID集合，用SET GTID_NEXT='xxx'+BEGIN; COMMIT;人工补全缺失区间（极少需要，仅调试场景） - 导入后立即执行
SELECT @@global.gtid_executed;验证——输出必须和备份时刻完全一致，否则说明导入过程有事务被跳过或重复
PURGE BINARY LOGS会破坏GTID定位能力
GTID定位依赖主库binlog中保留所有已执行事务的事件。一旦PURGE BINARY LOGS删掉某段binlog，对应GTID就永远丢失，从库再也无法通过MASTER_AUTO_POSITION = 1追平。
- 检查
SELECT @@global.gtid_purged;是否为空——非空说明已有GTID被PURGE，此时CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1大概率失败，报错Could not find first log file name in binary log index file - 生产环境建议设置
binlog_expire_logs_seconds = 2592000（30天），而非依赖PURGE命令；定期用SHOW BINARY LOGS确认最老binlog文件时间戳早于备份时间点 - 若已PURGE，唯一补救方式是重新做一次全量备份，并在新备份中记录当前
gtid_executed作为新起点
真正容易被忽略的是：GTID定位不是备份工具的内置能力，而是你操作链路中每个环节的手动衔接点——gtid_executed要记准、binlog要留够、RESET MASTER要慎用。少一个动作，恢复时就卡在“找不到GTID”上。
