本文首发于「数据库干货铺」公众号转载请联系授权。那是一个平静的夜晚突然手机响起急促的告警声——线上MySQL从库数据同步异常业务部门反映主从数据不一致部分读请求获取到了过期数据。经过紧急排查问题竟然源于一次看似普通的备份恢复操作。一、事件回顾一次正常的备份恢复事情的起因是某诺因“降本增效”需将集群1的数据库迁移到集群2,示例如下为了进行数据迁移使用mysqldump对生产库做了全量备份mysqldump -uroot -p -S /tmp/mysql.sock --set-gtid-purgedON --all-databases --triggers --routines --events --master-data2 full_backup.sql随后在目标集群的主库上执行了导入mysql -uroot -p full_backup.sql导入过程一切正常没有报错信息。然而问题悄然出现目标集群的从库没有自动同步这些数据导致主从数据不一致。二、问题根源GTID机制与备份参数解析1. 什么是GTIDGTID全局事务标识符是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-purgedON的备份文件头SET GLOBAL.GTID_PURGED84e06268-dfa5-11e7-b0bc-080027a59108:1-2;SET SESSION.SQL_LOG_BIN0;后续是正常的建表和数据插入语句使用--set-gtid-purgedOFF的备份文件没有GTID相关设置直接是建表和数据插入语句3. 问题所在SQL_LOG_BIN0的副作用尤其可见当--set-gtid-purgedON或者不设置时默认值即为ON时备份文件会设置SESSION.SQL_LOG_BIN0这意味着导入数据时不会产生binlog因此从库无法通过复制获取这些数据。因此之前备份恢复至模板集群就是此原因导致。即完整的流程如下三、解决方案正确使用备份参数1. 不同场景的参数选择根据实际需求选择合适的备份参数场景1搭建从库或重建复制mysqldump --set-gtid-purgedON ... backup_for_slave.sql场景2在主库上恢复部分数据mysqldump --set-gtid-purgedOFF ... backup_for_master.sql2. 紧急修复方案如果已经错误地在主库导入了包含SET GLOBAL.GTID_PURGED的备份可以采用以下修复措施在主库上重新导入正确备份但是前提是可以重新重复执行如果新集群已产生数据则不建议重新导入mysql -uroot -p -e SET SESSION SQL_LOG_BIN1; SOURCE full_backup_fixed.sql;使用逻辑方式重新同步数据或用percona工具中的pt-table-sync进行修复pt-table-sync --host主库IP --userroot --passwordxxx h从库IP,D数据库,t表 --execute完整的修复文章可以参考历史文章MySQL数据库主从数据对比及修复3. 从库重新搭建流程如果重新搭建从库可以考虑重新备份然后重做从库大致的流程如下-- 在从库上执行STOP SLAVE;RESET SLAVE;RESET MASTER;-- 导入备份数据SOURCE full_backup.sql;-- 重新配置复制CHANGE MASTER TO MASTER_HOSTmaster_ip, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDxxx, MASTER_AUTO_POSITION1;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 --userroot --passwordxxx四、小结MySQL将set-gtid-purged默认设置为AUTO效果同ON主要是为了保证复制的完整性。在GTID模式下每个事务都必须有唯一标识如果备份时不包含GTID信息可能会破坏事务的连续性。但这种安全第一的设计理念却给不熟悉GTID机制的用户带来了隐患。这提醒我们在使用任何数据库功能前都必须深入理解其工作原理和适用场景。这次故障给我们敲响了警钟在GTID环境下备份恢复不再是简单的数据搬运而是需要综合考虑复制拓扑、事务一致性和业务需求的复杂操作。希望本文能帮助大家避免类似的坑位让数据库运维工作更加顺畅。如果你有更好的GTID实战经验欢迎留言分享交流关注微信公众号「数据库干货铺」获取更多数据库运维干货。