本文首发于「数据库干货铺」公众号，转载请联系授权。
那是一个平静的夜晚，突然手机响起急促的告警声——线上MySQL从库数据同步异常！业务部门反映主从数据不一致，部分读请求获取到了过期数据。经过紧急排查，问题竟然源于一次看似普通的备份恢复操作。
一、事件回顾：一次"正常"的备份恢复
事情的起因是某诺因“降本增效”需将集群1的数据库迁移到集群2,示例如下：
为了进行数据迁移，使用mysqldump对生产库做了全量备份：
mysqldump -uroot -p -S /tmp/mysql.sock --set-gtid-purged=ON --all-databases --triggers --routines --events --master-data=2 > full_backup.sql随后在目标集群的主库上执行了导入：
mysql -uroot -p < full_backup.sql导入过程一切正常，没有报错信息。然而问题悄然出现：目标集群的从库没有自动同步这些数据，导致主从数据不一致。
二、问题根源：GTID机制与备份参数解析
1. 什么是GTID？
GTID（全局事务标识符）是MySQL 5.6+引入的重要特性，其格式为source_id:transaction_id，例如：
e1e2f3a4-5678-90ab-cdef-1234567890ab:1GTID的两大核心作用：
事务全局唯一标识：每个事务在集群中都有唯一ID
自动容错定位：主从切换后，从库自动找到正确同步位置
2. mysqldump的--set-gtid-purged参数
set-gtid-purged这个参数控制是否在备份文件中包含GTID信息，其参数值有ON、OFF两种：
ON/AUTO（默认值）：备份文件包含SET @@GLOBAL.GTID_PURGED语句
OFF：不包含任何GTID相关信息
两种设置的实际差异如下：
使用--set-gtid-purged=ON的备份文件头：
SET @@GLOBAL.GTID_PURGED='84e06268-dfa5-11e7-b0bc-080027a59108:1-2';SET @@SESSION.SQL_LOG_BIN=0;后续是正常的建表和数据插入语句
使用--set-gtid-purged=OFF的备份文件：
没有GTID相关设置，直接是建表和数据插入语句
3. 问题所在：SQL_LOG_BIN=0的副作用
尤其可见，当--set-gtid-purged=ON（或者不设置时默认值即为ON）时，备份文件会设置SESSION.SQL_LOG_BIN=0，这意味着导入数据时不会产生binlog，因此从库无法通过复制获取这些数据。
因此，之前备份恢复至模板集群就是此原因导致。即完整的流程如下：
三、解决方案：正确使用备份参数
1. 不同场景的参数选择
根据实际需求选择合适的备份参数：
场景1：搭建从库或重建复制
mysqldump --set-gtid-purged=ON ... > backup_for_slave.sql场景2：在主库上恢复部分数据
mysqldump --set-gtid-purged=OFF ... > backup_for_master.sql2. 紧急修复方案
如果已经错误地在主库导入了包含SET @@GLOBAL.GTID_PURGED的备份，可以采用以下修复措施：
在主库上重新导入正确备份，但是前提是可以重新重复执行，如果新集群已产生数据则不建议重新导入
mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=1; SOURCE full_backup_fixed.sql;"使用逻辑方式重新同步数据或用percona工具中的pt-table-sync
进行修复
pt-table-sync --host=主库IP --user=root --password=xxx h=从库IP,D=数据库,t=表 --execute完整的修复文章可以参考历史文章：
MySQL数据库主从数据对比及修复
3. 从库重新搭建流程
如果重新搭建从库，可以考虑重新备份，然后重做从库，大致的流程如下：
-- 在从库上执行STOP SLAVE;RESET SLAVE;RESET MASTER;-- 导入备份数据SOURCE full_backup.sql;-- 重新配置复制CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;START SLAVE;一定注意恢复前的检查，重点确认如下内容：
目标实例的GTID状态：SHOW GLOBAL VARIABLES LIKE 'gtid_purged'
备份文件的GTID信息：head -n 50 ${BACKUP_FILE} | grep GTID_PURGED
实例角色（主库还是从库）
业务影响时间窗口
恢复完成后务必做好检查：
-- 检查主从同步状态SHOW SLAVE STATUS\G-- 确认Seconds_Behind_Master为0-- 确认Slave_IO_Running和Slave_SQL_Running为Yes-- 检查数据一致性pt-table-checksum --host=主库IP --user=root --password=xxx四、小结
MySQL将set-gtid-purged默认设置为AUTO（效果同ON），主要是为了保证复制的完整性。在GTID模式下，每个事务都必须有唯一标识，如果备份时不包含GTID信息，可能会破坏事务的连续性。但这种"安全第一"的设计理念，却给不熟悉GTID机制的用户带来了隐患。这提醒我们：在使用任何数据库功能前，都必须深入理解其工作原理和适用场景。
这次故障给我们敲响了警钟：在GTID环境下，备份恢复不再是简单的数据搬运，而是需要综合考虑复制拓扑、事务一致性和业务需求的复杂操作。
希望本文能帮助大家避免类似的坑位，让数据库运维工作更加顺畅。如果你有更好的GTID实战经验，欢迎留言分享交流！
关注微信公众号「数据库干货铺」，获取更多数据库运维干货。
)
