gtid_mode=on必须配合enforce_gtid_consistency=on，否则触发error 1786；需删auto.cnf防server-uuid冲突，且change master to必须用master_auto_position=1。
gtid_mode=ON 必须开启，但光开这个远远不够——配置错误会导致复制中断、GTID集合错乱，甚至从库拒绝启动。
主从都必须确认 enforce_gtid_consistency 为 ON
这个参数不是可选的“建议项”，而是 GTID 复制的硬性前提。设为 WARN 或 OFF 时，MySQL 允许执行不安全语句（比如 CREATE TABLE ... SELECT、事务内 DROP TEMPORARY TABLE），这些操作在 GTID 模式下无法被正确记录或跳过，最终触发复制报错：ERROR 1786 (HY000): Statement violates GTID consistency。
- 必须在
my.cnf中显式写enforce_gtid_consistency=ON，不能依赖运行时 SET（该变量只读） - 生效前需重启 mysqld，且重启后执行
SHOW VARIABLES LIKE 'enforce_gtid_consistency';确认值为ON - 应用层需提前清理不兼容 SQL；若无法立即改造，先用
WARN模式跑几天，抓日志里的警告再修复
SET @@GLOBAL.gtid_purged 在导入 dump 时极易踩坑
mysqldump 默认会在输出头部写入 SET @@GLOBAL.gtid_purged = '...';，它的行为在 MySQL 8.0 和 5.7 完全不同：8.0 是「追加」到现有 gtid_purged 集合，而 5.7 是「覆盖」。如果从库已有 GTID 历史（比如已运行过复制），直接 source 这个 dump 会把旧 GTID 清掉，导致后续 CHANGE MASTER TO 失败或丢事务。
- 新空从库：保留该语句，它能正确初始化
gtid_purged - 已有数据的从库（如多源复制、重建部分库）：必须手动删除或注释掉这行，再导入
- 不确定时，先查
SELECT @@global.gtid_purged;—— 若非空字符串，就别让 dump 自动改它
从库 server-id 和 server-uuid 冲突是静默故障源
复制链路里 server-id 重复只会让从库报错拒绝启动，但 server-uuid 重复更危险：它不会立即报错，却会导致 GTID 集合混淆、事务被误判为“已在本地执行”而跳过，数据悄悄丢失。
-
server-id：主从必须不同，范围 1–4294967295，写进my.cnf即可 -
server-uuid：由 MySQL 启动时自动生成并存于auto.cnf，克隆虚拟机后必须删掉原/var/lib/mysql/auto.cnf文件，重启 mysqld 生成新 UUID - 验证命令：
SELECT @@server_uuid;，确保主从值完全不同
CHANGE MASTER TO 不要指定 MASTER_LOG_FILE 和 MASTER_LOG_POS
启用 GTID 后，这两个参数不仅无效，还会干扰自动定位。MySQL 会忽略它们，但若值与当前 Executed_Gtid_Set 冲突，可能触发 ERROR 3021 (HY000) 或复制停滞。
- 正确写法只保留网络和账号信息：
CHANGE MASTER TO MASTER_HOST='192.168.1.101', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1; -
MASTER_AUTO_POSITION=1是关键开关，它告诉从库用 GTID 自动对齐位点 - 执行前确保从库已清空 relay log（
RESET SLAVE），否则残留日志可能干扰 GTID 匹配逻辑
binlog_format=ROW 和 log_slave_updates=ON 的组合影响：前者保证 DML 可精确重放，后者让从库也生成 binlog（级联复制必需）。但若从库没开 log_slave_updates，又启用了 GTID，Executed_Gtid_Set 会漏掉从库自己执行的事务，导致下游从库同步失败——这种问题只在三层及以上拓扑中暴露，调试成本极高。
