不是必须，但不开启 log_slave_updates 会导致从库无法作为新主库参与故障切换；启用 GTID 后必须使用 MASTER_AUTO_POSITION=1，禁用 MASTER_LOG_FILE/POS；导出需加 --set-gtid-purged=ON；表结构不一致是 DROP TABLE 报错主因。
MySQL 5.6+ 开启 GTID 前必须关掉 log_slave_updates 吗？
不是必须，但不开启会导致从库无法作为新主库参与故障切换——这是 GTID 复制里最常被忽略的因果链。
GTID 要求所有事务在复制链路上有唯一、可追踪的 ID。如果从库没开 log_slave_updates，它执行的 relay log 事务就不会写入自己的 binlog，后续再把它提升为主库时，下游从库就找不到同步起点，START SLAVE UNTIL SQL_BEFORE_GTIDS 之类操作直接失效。
- 生产环境建议默认开启：
log_slave_updates = ON - 仅在极简测试场景（比如单层主从、永不升主）可关，但要清楚代价
- 开启后 binlog 体积略增，但对性能影响微乎其微；MySQL 5.7+ 已优化写入路径
CHANGE MASTER TO 配合 GTID 时不能指定 MASTER_LOG_FILE 和 MASTER_LOG_POS
一旦启用 GTID（gtid_mode = ON），MySQL 会拒绝带文件名和位置的 CHANGE MASTER 指令，报错：ERROR 1777 (HY000): Changing the master configuration is not allowed while @@GLOBAL.GTID_MODE = ON。
原因很简单：GTID 模式下，MySQL 不再依赖“哪个文件第几行”这种物理位点，而是靠 GTID_SET 做逻辑寻点。硬塞 binlog 文件名，系统没法验证一致性，直接拦截。
- 正确做法是用
MASTER_AUTO_POSITION = 1：CHANGE MASTER TO MASTER_HOST='10.0.1.2', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION = 1;
- 如果要跳过某段 GTID（比如跳过误删语句），得先查
SELECT @@global.gtid_executed;，再用SET GLOBAL gtid_purged = '...';注入跳过集，而不是改 pos - 注意：
gtid_purged只能设为空或比当前gtid_executed更小的集合，否则报错
从库启动失败，报错 Client requested master to start replication from position > file size 怎么办？
这通常不是 GTID 本身的问题，而是混用了传统模式恢复 + GTID 启动流程——比如用 mysqldump --master-data=2 导出时没加 --set-gtid-purged=ON，导致 dump 文件里写死了旧的 binlog 文件名和位置，而你又在 GTID 模式下执行了它。
结果就是 MySQL 尝试按 dump 里的 CHANGE MASTER TO ... MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1234 去找位点，但那个文件可能已被 purge，或者压根不存在。
- 导出时务必加：
mysqldump --all-databases --single-transaction --set-gtid-purged=ON > backup.sql - 导入后，检查
SELECT @@global.gtid_executed;是否与 dump 文件头部的SET @@GLOBAL.gtid_purged一致 - 若已出错，别硬启 slave；先
RESET SLAVE ALL清空所有复制状态，再用MASTER_AUTO_POSITION = 1重配
为什么主库执行 DROP TABLE 后，从库报 Could not execute Drop_table event on table xxx; Error_code: 1051？
这不是 GTID 特有，但 GTID 会让这类问题更难绕过——因为传统模式下你可以临时关 SQL 线程、手工删表再启，而 GTID 要求事务必须严格按 GTID 序列执行，跳过一个事务就得显式设置 gtid_skip，操作门槛高且易出错。
根本原因是主从表结构不一致，常见于手动 DDL 未走复制、或从库被人工干预过。
- 优先查
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set差异，确认是否卡在某个 GTID - 临时跳过（仅调试）：
STOP SLAVE;<br>SET GTID_NEXT="aabbccdd-eeff-1122-3344-556677889900:12345";<br>BEGIN; COMMIT;<br>SET GTID_NEXT="AUTOMATIC";<br>START SLAVE;
- 长期方案：所有 DDL 必须经主库执行，禁用从库写入；用
pt-table-checksum定期校验表一致性
Executed_Gtid_Set 里缺了一段却找不到对应事务日志时。 
