GTID模式主从复制：告别“开箱即用”的配置实战
想用GTID模式搭建MySQL主从？先别急着执行CHANGE MASTER TO。这事儿不是“开箱即用”的，如果没在主从双方提前打好基础，命令一敲下去，大概率会直接撞上ERROR 1777 (HY000)这个拦路虎。核心就一句话：必须确保主库和从库都同时启用了gtid_mode=ON，并且enforce_gtid_consistency也得是ON状态。
主库必须开启的三项关键配置
你以为把gtid_mode改成ON就万事大吉了？远远不够。MySQL对GTID的启用有严格的“捆绑销售”策略，下面这三项配置，缺了任何一个，服务都启动不了：
gtid_mode=ON：这是根本，负责生成和识别全局事务ID。enforce_gtid_consistency=ON：这是“纪律委员”，强制所有事务遵守GTID的规则，比如会禁止创建临时表、使用非确定性函数等可能引发数据不一致的操作。log_bin=ON：这是“记录员”，GTID本身依赖二进制日志来记录事务，所以binlog必须开启。
对于已经在线上运行的实例，如果之前没开log_bin，那可得小心了。重启前务必确认磁盘空间充足，建议将binlog_format设置为ROW，并且——这一点很重要——尽量避开业务高峰期操作。
从库执行 CHANGE MASTER TO 的正确写法
到了配置从库连接主库这一步，GTID模式就和传统基于文件和位置（file/pos）的模式分道扬镳了。你不再需要费劲地去指定MASTER_LOG_FILE和MASTER_LOG_POS，取而代之的是一个更智能的参数：MASTER_AUTO_POSITION=1。它会自动根据双方已有的GTID集合来对齐位置。
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;
这里有几个常见的坑，一不小心就会踩进去：
- 最典型的错误就是漏写了
MASTER_AUTO_POSITION=1，却还带着MASTER_LOG_FILE参数，结果就是报错。 - 主库上复制账号的权限没给对，或者没执行
FLUSH PRIVILEGES，会导致从库IO线程一直卡在Connecting状态。 - 如果从库不是一张“白纸”（
gtid_executed集合非空），而且它的GTID集合和主库的没有任何交集，复制也会启动失败。这时候，可能需要对从库执行RESET MASTER来清空GTID历史（操作前请务必评估影响）。
验证复制状态时重点看这三项
配置完启动复制，跑一下SHOW SLA VE STATUS\G，别只扫一眼Sla ve_IO_Running和Sla ve_SQL_Running显示“Yes”就以为高枕无忧了。真正判断GTID复制是否健康，得盯着下面这三个关键指标：
Retrieved_Gtid_Set：这里必须是非空的，并且随着时间推移不断增长，这证明IO线程正在持续地从主库拉取二进制日志。Executed_Gtid_Set：这个集合应该和Retrieved_Gtid_Set基本同步，两者差值保持稳定甚至为0，说明SQL线程跟得上，没有积压。Auto_Position: 1：这个必须确认是1，它标志着当前复制确实运行在GTID自动定位模式，而不是悄悄降级回了传统的文件位置模式。
如果发现Executed_Gtid_Set长时间不动，而Retrieved_Gtid_Set却在涨，那基本可以断定SQL线程卡住了。可能是遇到了DDL冲突，或者是权限问题。此时，Seconds_Behind_Master延迟会飙升，具体的错误信息就藏在Last_SQL_Error字段里，需要仔细查看。
最后，必须提醒的是，GTID模式带来便利的同时，也引入了一个隐性成本：它对binlog的保留策略更为敏感。一旦主库的gtid_purged集合（即已清理的GTID集合）包含了从库尚未获取的事务，那么这个从库就永远无法通过自动定位来补全数据了。因此，设置binlog_expire_days时，一定要预留出大于从库可能出现的最大延迟时间，这一点比传统复制模式要严格得多。
