MySQL如何配置GTID主从复制_使用全局事务ID简化主从切换

GTID模式开启前必须停写并校验主从一致性

很多朋友踩过的第一个坑，就是以为GTID是个简单的开关，直接在主从库的配置文件里加上gtid_mode=ON就完事了。结果呢？MySQL直接给你一个ERROR 1782 (HY000): Statement violates GTID consistency。这可不是配置顺序不对，而是主从库当前的事务历史压根就没对齐，MySQL拒绝在这种“账本”不一致的情况下开启新机制。

所以，正确的操作流程，其实是一场精密的“账本”核对工作：

• 首先，在主库上执行FLUSH TABLES WITH READ LOCK锁住所有表，然后立刻记下SHOW MASTER STATUS命令输出的Executed_Gtid_Set。这个值就是主库的“最终账目”。
• 接着，在从库上，根据刚才记下的主库binlog文件名和位置，执行SELECT MASTER_POS_WAIT('binlog_file', position)，耐心等待从库追平。这里要特别注意，不能只看Seconds_Behind_Master=0，那个指标有时会“骗人”。
• 追平之后，才是关键一步：分别在主库和从库执行SELECT @@global.gtid_executed，确保两个字符串完全一致。如果不一致，通常意味着有“匿名事务”（比如老版本升级留下的）没有被纳入GTID体系，必须清理干净。
• 最后，在解锁之前，务必确认所有应用写入都已停止，否则锁一释放，新事务进来，刚才的核对工作就白做了。

my.cnf里这5个参数缺一不可且顺序敏感

GTID是一套组合拳，不是单兵作战。配置文件里漏掉任何一个参数，或者顺序摆错了，都可能导致复制中断、切换失败，甚至数据丢失。这几个参数，主从库都得配，但各有讲究。

下面这个组合，可以说是GTID的“标准套餐”：

• gtid_mode=ON：核心开关。必须设为ON。ON_PERMISSIVE这种过渡状态，玩玩可以，千万别用在生产环境的主从复制上。
• enforce_gtid_consistency=ON：这是GTID的“纪律委员”。它会强制禁止那些无法安全记录在GTID中的SQL语句，比如创建临时表、或者INSERT里用了UUID()函数。如果不开启，复制线程遇到这类语句会直接退出。
• log_bin和binlog_format=ROW：这是GTID的“记录本”。二进制日志必须开启，而且格式必须为ROW。如果还用STATEMENT或者MIXED格式，很快就会触发ERROR 1785。
• server_id：这是每个MySQL实例的“身份证”。必须全局唯一，不能是0或者空字符串。现在用Docker或者云数据库比较多，要特别小心自动生成的server_id可能重复，一定要检查。

CHANGE MASTER TO不再用FILE/POSITION，改用GTID自动定位

切换到GTID模式后，以前那套基于文件名和位置的连接方式就彻底失效了。如果你还试图用CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154，会直接收到ERROR 1777的报错。

现在，一切都变得自动化了。正确的做法是让从库根据自己已经执行过的事务集合（GTID Set），去主库自动“查漏补缺”：

• 在配置从库之前，先用RESET SLA VE ALL彻底清空旧的复制信息。注意，是ALL，光用RESET SLA VE不会清理gtid_purged，会留下隐患。
• 设置主库连接信息时，直接省略掉日志文件和位置，加上关键参数：CHANGE MASTER TO MASTER_HOST='10.0.1.2', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1。
• 这个MASTER_AUTO_POSITION=1就是精髓。它告诉从库：“你去和主库自动协商一下，看看你缺了哪些事务，然后只拉取缺失的部分。” 完全不用人工去计算和指定位置。
• 当然，这里有个前提：主库上尚未清理的事务（gtid_purged）必须包含从库已有的所有GTID。如果不包含，复制启动会失败。这时，如果从库是全新的或者数据可丢弃，可以用SET GLOBAL gtid_purged = 'xxx-yyy:1-100'来手动补全这个集合。

主从切换后原主库的gtid_purged容易被忽略

GTID简化了切换，但并没有把所有的脏活累活都自动化。故障切换之后，有一个细节特别容易被忽略，那就是原主库（现在降级为从库了）的gtid_purged状态。

如果不处理，下次再把角色切回去时，复制链路可能会跳过大量事务，导致数据静默不一致。典型的症状就是：切换后，在原主库上查看SHOW SLA VE STATUS\G，会发现Retrieved_Gtid_Set是空的，而Executed_Gtid_Set却远远大于新主库，复制线程看似正常，却一直卡在Waiting for master to send event的状态。

怎么解决呢？需要在降级后的原主库上执行以下操作：

• 首先，停止复制：STOP SLA VE。
• 然后，有两种选择。一种是使用RESET MASTER重置所有GTID状态，但这招比较狠，会清空所有binlog，仅适用于确认这个库上没有需要保留的有效数据时。
• 更安全的做法是：执行SET GLOBAL gtid_purged = '新主库的gtid_executed值'，将自身的purged集合对齐到新主库，然后再START SLA VE。
• 操作完成后，可以通过SELECT * FROM performance_schema.replication_connection_status\G来验证，确保LAST_ERROR_MESSAGE字段为空。

这个步骤目前还没有完美的自动化方案，每次主从角色发生变更，都需要人工干预。如果在运维脚本里漏掉了这一步，就等于埋下了一个可能导致数据 silently（静默）丢失的隐患，务必警惕。