为什么MySQL 8.0中推荐使用基于GTID的复制而非位点？

MySQL 8.0默认启用GTID是为了替代易出错的位点复制，通过事务唯一标识实现自动差集同步；启用需主从均设gtid_mode=ON、enforce_gtid_consistency=ON，并用MASTER_AUTO_POSITION=1代替文件位置参数。

MySQL 8.0 默认启用 GTID，不是为了“新潮”，而是位点复制在真实运维中容易卡死、配错、跳过错误后数据不一致——GTID 把“事务”本身变成可识别、可比对、可跳过的实体，让主从关系从“靠人记日志位置”升级为“靠系统算集合差”。

CHANGE MASTER TO 为什么能省掉 MASTER_LOG_FILE 和 MASTER_LOG_POS

因为 GTID 模式下，从库启动复制时不再依赖人工指定的文件名和偏移量，而是通过 MASTER_AUTO_POSITION=1 告诉 MySQL：“我只缺没执行过的事务”。MySQL 会自动比对 gtid_executed（本地已执行的 GTID 集合）和主库提供的事务流，拉取差集。

1. 传统位点复制必须手动执行 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345，一旦备份时间与日志轮转不匹配，或日志被 purge，立刻报错 Could not find first log file name in binary log index file
2. GTID 下只要主从都开启 gtid_mode=ON 且 enforce_gtid_consistency=ON，一句 CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION=1 就够
3. 注意：MASTER_AUTO_POSITION=1 不是“智能猜测”，它严格依赖双方 gtid_executed 和 gtid_purged 的集合运算，所以初始同步时必须用 mysqldump --set-gtid-purged=ON 导出，否则从库 gtid_purged 为空，主库无法判断该发哪些事务

故障切换时为什么不用再找位点、算偏移

传统一主两从架构中，如果主库宕机，需人工对比两个从库的 SHOW SLAVE STATUSG 中的 Exec_Master_Log_Pos 和 Relay_Master_Log_File，再从 binlog 里逐条确认哪个从库更全；GTID 下只需看 SELECT GTID_SUBSET(gtid_executed, 'xxx:yyy') FROM performance_schema.global_variables 或直接比 SELECT @@global.gtid_executed 字符串长度，长的那个就是最新。

1. 切换新主库后，其他从库只需执行 STOP SLAVE; CHANGE MASTER TO MASTER_HOST='new_master_ip', MASTER_AUTO_POSITION=1; START SLAVE;，自动追平
2. 位点模式下，新主库可能已 purge 掉旧主库的 binlog，导致其他从库找不到起始位置，只能停服重搭
3. GTID 的 server_uuid:transaction_id 是全局唯一身份证，事务在哪台机器上提交过、执行过，系统自己记得清清楚楚

为什么 GTID 从库必须开 log_bin 和 log_slave_updates

因为 GTID 要求每个节点都能回答“这个事务我执行过了吗”，而判断依据就是它自己的 binlog 里有没有这条 GTID。如果从库不写 binlog，就无法维护 gtid_executed，复制链路在级联场景下会断裂。

1. 不启用 log_bin 会直接报错：ERROR 1792 (HY000): Changing the master configuration on a server running with GTID enabled is not allowed without enabling binary logging
2. log_slave_updates=1 必须开，否则从中继日志（relay log）回放的事务不会写进本机 binlog，gtid_executed 就漏了这部分，下游从库无法正确比对
3. 这意味着 GTID 从库磁盘 IO 和存储占用天然更高，尤其是大事务多、QPS 高的场景，得提前评估容量和刷盘压力

跳过错误事务为什么不能用 sql_slave_skip_counter

因为 sql_slave_skip_counter 是按 event 条数跳，而 GTID 是以完整事务为单位管理的。跳 1 条可能只跳过 BEGIN，留下 COMMIT 和后续语句，破坏原子性。

1. GTID 下跳错必须显式注入空事务：SET GTID_NEXT='xxx:yyy'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';
2. 其中 xxx:yyy 是 SHOW SLAVE STATUSG 中 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的差集里的那个 GTID
3. 跳完要立刻执行 SELECT @@global.gtid_executed 确认该 GTID 已出现在集合里，否则下次启动复制仍会重试

真正麻烦的不是配置 GTID，而是理解它把“事务身份”作为基础设施这件事——所有操作都围绕 GTID_SET 的交并补展开，而不是文件+偏移的线性坐标。一旦习惯这种思维，位点复制那种反复查日志、算位置、怕 purge 的焦虑感就消失了；但反过来，如果只是机械照搬参数却没校验 gtid_purged、忽略 log_slave_updates 的必要性，反而会让问题更隐蔽。