GTID复制取代传统位点复制，因其自动定位同步位置、避免人工计算位点错误、支持脚本化运维及强制事务级一致性；MySQL 8.0中GTID已成为自动化底座，mysqldump、clone plugin等核心功能均强依赖GTID。
MySQL 8.0 默认不推荐传统基于 binlog 文件名 + position 的复制，根本原因不是“不能用”，而是它在自动化运维中天然不可靠、不可收敛、极易出错。
为什么 CHANGE MASTER TO MASTER_LOG_FILE/MASTER_LOG_POS 在生产中越来越危险
位点复制依赖人工确认主库当前 mysql-bin.000012 的第 123456789 字节位置，这个值在以下场景会瞬间失效：
- 主库 binlog 被 purge（哪怕只删了一天前的文件，
SHOW MASTER LOGS就可能看不到原文件） - 主库重启后 binlog 自动轮转，
mysql-bin.000012可能被重命名为mysql-bin.000013，但从库还在等旧文件 - 主从之间存在延迟时，人为计算位点极易错估（尤其跨多跳复制链）
- failover 后，新主库的位点与旧主库完全不对应，必须人工比对所有从库的
Seconds_Behind_Master和Relay_Master_Log_File/Exec_Master_Log_Pos才能选最全节点 —— 这个过程无法脚本化
GTID 如何让 CHANGE MASTER TO 变成一行命令
启用 GTID 后，从库只需执行：
CHANGE MASTER TO MASTER_HOST='10.0.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;
MySQL 内部自动完成三件事：
- 读取主库的
gtid_executed集合 - 对比自己已执行的
gtid_executed，算出差集 - 直接拉取缺失的 GTID 对应事务，无需关心文件名或字节偏移
这意味着：搭建新从库、切换主库、重建复制链，全部可固化为 Ansible 或 Shell 脚本，无需 DBA 登录判断位点。
GTID 复制下跳过错误事务的真实代价
传统位点复制跳错常用 SET GLOBAL sql_slave_skip_counter=1，但它本质是“跳过下一条语句”，而语句级跳过在 ROW 格式 binlog 下极可能破坏数据一致性。
GTID 下跳过必须显式指定 GTID：
STOP SLAVE; RESET MASTER; SET @@GLOBAL.GTID_PURGED = 'f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32'; START SLAVE;
这看似麻烦，实则是强制你确认“要丢弃的是哪个事务”，而不是模糊地跳“一条”。真正容易被忽略的是：GTID_PURGED 设置后，该实例永远无法再接收 f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32 范围内的任何事务 —— 即使上游重放一遍也不行。所以跳 GTID 不是“绕开错误”，而是永久性声明“这部分数据我不要了”。
MySQL 8.0 中 GTID 已不是可选项，而是自动化底座
MySQL 8.0 的 mysqldump --set-gtid-purged=ON、mysqlpump、clone plugin、甚至 group_replication 模块，全部强依赖 GTID。禁用 GTID 后，这些功能要么报错，要么退化为不可靠的手动模式。
更关键的是：MySQL 8.0 的 gtid_mode 切换流程（OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON）已足够平滑，但前提是主从两端必须同步操作，且 enforce_gtid_consistency=ON 必须先于 gtid_mode=ON 设置 —— 这个顺序一旦颠倒，SET GLOBAL gtid_mode = ON 会直接报错 ERROR 1782 (HY000)，且无法回退。
