GTID模式本身不自动保证数据一致性，仅支持可验证、可追溯、可自动恢复；丢数据主因是未满足enforce_gtid_consistency=ON、引擎统一为InnoDB、log_slave_updates=ON三大前提。
GTID 模式本身不能自动保证主从切换后的数据一致性，它只是让一致性可验证、可追溯、可自动恢复——前提是配置正确、操作合规、引擎一致。
为什么 gtid_mode=ON 后主从切换还丢数据？
常见错误是只开了 GTID，却忽略了三个硬性前提：
-
enforce_gtid_consistency必须为ON，否则像CREATE TEMPORARY TABLE、LOAD DATA INFILE、混合引擎事务（如 InnoDB + MyISAM）都会被允许执行，但这些操作无法生成合法 GTID，导致从库 SQL 线程报错中断，后续事务堆积，切换时直接跳过未执行的 GTID 区间 - 主从表存储引擎必须统一为
InnoDB；MyISAM 表不支持事务，其 DML 不写入 binlog 的事务上下文，GTID 无法关联，复制链路在该语句处断裂 - 从库必须开启
log_slave_updates=ON（尤其在级联或双主场景），否则它执行的 GTID 不会写入自己的 binlog，无法作为新主继续提供复制服务
MASTER_AUTO_POSITION = 1 的真实作用与限制
这个参数不是“万能同步开关”，而是告诉从库：别再靠 CHANGE MASTER TO ... MASTER_LOG_FILE, MASTER_LOG_POS 手动找位点，改用 GTID 集合自动比对缺失事务。
但它依赖两个关键状态：
- 主库的
gtid_executed必须完整（不能被PURGE BINARY LOGS过度清理），否则从库请求的 GTID 在主库已不存在，START SLAVE直接报错Could not find first log file name in binary log index file - 从库自身的
gtid_executed和gtid_purged必须逻辑自洽；若误执行RESET MASTER，gtid_purged被清空但 relay log 里还有未执行事务，会导致 GTID 冲突、复制拒绝启动 - 主从
server_uuid绝对不能重复（查看/var/lib/mysql/auto.cnf），UUID 冲突会让从库拒绝接收同 UUID 的 GTID，表现为Slave has more GTIDs than the master类错误
主从切换时最容易忽略的三步验证
切主前不验证这三项，90% 的“一致性”只是幻觉：
- 查
SELECT @@global.gtid_executed;对比主从是否完全一致（注意：需在STOP SLAVE后查，避免 SQL 线程正在追平造成瞬时偏差） - 查
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否相等，不等说明 relay log 有积压，必须等Seconds_Behind_Master = 0且两者相等才可切 - 执行
SELECT * FROM mysql.gtid_executed;看是否有跨 UUID 的断点（例如某 UUID 的 TID 序列中间缺了一段），这种“空洞”意味着事务丢失，不能直接提升为新主
GTID 的价值不在“自动同步”，而在“精确知道哪里断了、缺什么、能不能补”。真正决定一致性的，永远是操作前的校验动作、引擎约束、以及对 gtid_purged 和 auto.cnf 这类底层文件的敬畏心。
