MySQL还原备份方法3单独写GTID就是因为这个方法跟前两种完全不是一个套路。传统方式做还原要先记binlog文件名和position然后在新实例上手动指过去中间差一个事务都容易对不上。GTID方案直接把“全局唯一事务ID”这件事交给MySQL自己管备份还原时只需要关心“这个事务集合长什么样”剩下的事情数据库自动帮你排除掉已执行过的事务。这篇我把这类还原的完整流程、GTID状态怎么读、踩过的坑都捋一遍适合正在搭从库、做数据迁移或定期做恢复演练的同学参考。1. GTID到底是啥为什么备份恢复绕不开它1.1 GTID的核心原理全局唯一的事务编号GTID的全称是Global Transaction Identifier全局事务标识符。每个在GTID模式下提交的事务都会在生成时获得一个全局唯一的编号格式是UUID:sequence_number。UUID是每个MySQL实例的server_uuidsequence_number是实例内自增的序号。比如3d3e5e9a-1a5a-11ef-9b3a-005056a35b5f:1-45这一串就代表某个源实例上从第1到第45个事务。这个设计把“在哪个实例的哪个binlog位置”变成了“我是哪个实例的第几个事务”。前者是坐标后者是身份证号。在做备份和恢复这种跨实例操作时坐标会随环境变化但身份证号永远不变。所以GTID非常适合用来做数据搬运和主从对齐——只要新实例拿到同一个事务集合它就知道自己该从哪里继续。1.2 为什么备份恢复要优先考虑GTID传统基于binlog position的恢复核心难处在于position是一个动态值。备份时记下的MASTER_LOG_FILE和MASTER_LOG_POS到了新环境之后如果中途还有别的实例在写数据或者源实例做过日志清理这个坐标可能就失效了。你去目标库执行CHANGE MASTER TO的时候甚至可能因为文件被purge而直接报错。GTID模式彻底绕开了这类问题。备份文件里记录的是gtid_executed的集合恢复时只需要一句话把所有事务补齐从库再通过MASTER_AUTO_POSITION1自动协商起点不需要人工去算“现在到底该从哪个binlog的哪个position开始接”。对经常搭从库、隔三差五做全量恢复的人来说这套机制能省掉大量人为核对的时间也降低了出错概率。这也是我在MySQL 5.7之后坚持所有实例统一开启GTID的核心原因。2. 动手前先看清GTID状态三个必查参数2.1 确认GTID是否开启gtid_mode和enforce_gtid_consistency做GTID备份恢复之前第一件事不是敲备份命令而是确认源实例和目标实例的GTID模式。最多人踩的坑就是源库开着GTID目标库没开或者反过来恢复完直接报错或者复制对不上。查看命令很简单SHOW VARIABLES LIKE gtid_mode; SHOW VARIABLES LIKE enforce_gtid_consistency;gtid_mode有几个值ON、OFF、ON_PERMISSIVE、OFF_PERMISSIVE。生产环境建议直接是ON。如果还是OFF备份还原逻辑就要走传统position方式这篇讲的GTID流就不适用了。另一个参数是enforce_gtid_consistency它控制哪些语句在GTID模式下允许执行。比如CREATE TABLE ... SELECT这种非事务性语句在GTID模式下默认是被禁止的。备份还原时如果出现这类报错不是你恢复姿势错了而是这个参数在把关。细节我放到第5章的问题排查里讲。2.2 读懂gtid_executed和gtid_purgedGTID模式下每个实例都有两个状态变量理解它们还原就成功了一半。gtid_executed表示当前实例上已经执行过的事务集合可以理解为“我做过的所有事”。gtid_purged表示已经被清理掉的事务集合通常是binlog被purge之后记录下来的“我不再有完整binlog历史的事务”。这两个值的关系要记清楚gtid_purged是gtid_executed的子集。一个事务如果已经被purge它必然已经执行过但执行过的事务不一定会被purge除非日志被清理了。查询方式SHOW GLOBAL VARIABLES LIKE gtid_purged; SHOW GLOBAL VARIABLES LIKE gtid_executed;也可以直接查性能表SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME IN (gtid_executed,gtid_purged);备份还原时主要关注gtid_purged。因为从备份文件恢复数据时MySQL通过设置gtid_purged来告诉新实例“这些事务在备份文件里已经包含了日志里虽然找不到但你不用再执行了”。2.3 备份前环境检查清单老话说得好备份恢复多花三分钟检查后面少熬三个小时夜。我每次做GTID还原前都会按下面这个清单过一遍源实例gtid_modeONenforce_gtid_consistencyON。源、目标实例server_uuid不能重复。如果是克隆虚拟机镜像导致的重复uuidSHOW VARIABLES LIKE server_uuid就能发现必须提前改掉否则复制链路直接起不来。目标实例gtid_executed如果非空要想清楚是否和备份的GTID集合有重叠。重叠会导致导入时自动跳过这未必是坏事但你要心里有数。目标实例至少保证有一个同步的空数据库实例最好干净到连二进制日志都没有历史事务的那种。3. GTID下的备份实操mysqldump和XtraBackup怎么选3.1 用mysqldump做逻辑备份并保留GTID信息mysqldump做GTID备份核心参数是--set-gtid-purged。这个参数有三个值AUTO、ON、OFF。ON在dump文件里写入SET GLOBAL.gtid_purged...恢复时能让目标实例快点对齐GTID状态。OFF不写任何GTID信息适合你只想导数据、不关心GTID流转的场景。AUTO默认值只有当前实例GTID开了才会输出GTID信息。我常用的备份命令mysqldump \ --single-transaction \ --set-gtid-purgedON \ --master-data2 \ --routines --triggers --events \ --all-databases \ -u备份账号 -p /data/backup/gtid_full_$(date %F).sql这里有个细节--single-transaction配合InnoDB可以让备份基于一致性快照不加锁业务还能正常写。--master-data2会把CHANGE MASTER TO信息以注释形式写到文件里虽然GTID模式下不依赖它但作为审计信息留着没坏处。备份完成后打开文件头部你会看到一段类似下面的内容-- GTID state at the beginning of the backup SET GLOBAL.gtid_purged3d3e5e9a-1a5a-11ef-9b3a-005056a35b5f:1-452345;这行就是后续恢复时目标实例用来对齐GTID的“锚”。如果这段内容在你恢复时没有生效那从库大概率会从错误的位置开始复制导致数据不一致。3.2 用XtraBackup做物理备份并记录GTID落点mysql逻辑备份适合中小规模库到了几百GB甚至上TB的量级一遍mysqldump能跑几个小时恢复也慢。物理备份XtraBackup这时候更合适。它直接拷贝数据文件加上redo log里的增量变化能做到近乎实时的物理一致性备份。备份命令相对简单xtrabackup --backup \ --target-dir/data/backup/full \ --user备份账号 \ --passwordxxx \ --host127.0.0.1备份结束后binlog位置和GTID信息会记录在几个文件里。关键有两个xtrabackup_binlog_info记录binlog文件名、position和GTID集合。xtrabackup_info包含更完整的备份元信息比如备份开始结束时间、lsn范围、GTID状态。这两个文件一般只有几行但千万别删。用XtraBackup做恢复时目标实例的对齐依据就是它们。如果你在备份后还开了--slave-info还会多一个xtrabackup_slave_info里面记录的是从库自己的复制信息搭建级联从库时特别有用。3.3 备份文件里的GTID信息怎么读不管用哪种工具GTID备份的本质都一样把数据库恢复到某个时间点同时告诉目标实例“这个时间点对应哪些事务”。所以拿到备份后建议第一时间把GTID信息摘出来记到备注里。恢复不顺利时这个备注能帮你快速判断是备份问题还是恢复流程问题。用mysqldump的话直接grepgrep -i gtid_purged /data/backup/gtid_full_2025-01-01.sql用XtraBackup的话cat /data/backup/full/xtrabackup_binlog_info cat /data/backup/full/xtrabackup_info | grep -i gtid我以前碰到过一次备份文件是好的但恢复之后数据总差一点的情况最后发现是拿错了备份那个时间点的GTID信息导致从库追日志追到一半卡住了。所以这个“读GTID”的过程虽然只有几秒钟但在整个恢复流程里价值非常大。4. 还原与恢复GTID事务如何落库4.1 全新恢复导入备份并让GTID对齐全新环境恢复是最简单也最典型的GTID还原场景。假设你拿到一份mysqldump生成的sql文件目标库是台全新实例还没有任何业务数据。导入流程分三步。第一步确保目标实例GTID模式开启。如果没开先在配置文件里加[mysqld] gtid_modeON enforce_gtid_consistencyON然后重启MySQL。第二步导入数据mysql -uroot -p /data/backup/gtid_full_2025-01-01.sql导入时dump文件里那条SET GLOBAL.gtid_purged...会把目标实例的gtid_executed和gtid_purged都设置成备份时刻的状态。导入完再查一下SHOW GLOBAL VARIABLES LIKE gtid_executed;你会看到结果和备份文件里记录的GTID完全一致。这就代表新实例已经站在了和源实例相同的时间点上。第三步如果是搭建从库执行CHANGE MASTER TO MASTER_HOST源实例IP, MASTER_USER复制账号, MASTER_PASSWORD密码, MASTER_AUTO_POSITION1; START SLAVE;看到这里你应该明白了整个搭建过程不需要再关心binlog文件名和position。MASTER_AUTO_POSITION1会自动让源实例把主库缺失的GTID事务发给从库从库已执行过的事务自动跳过天生不会重复执行。4.2 基于GTID搭建新从库省去binlog文件名和position计算老办法搭建从库最烦的一步就是从备份文件里找MASTER_LOG_FILE和MASTER_LOG_POS这两个字段差一个数字全盘白干。GTID模式下CHANGE MASTER TO只写MASTER_AUTO_POSITION1主从协商交给数据库自己逻辑非常干净。从性能角度说GTID自动定位还有一个隐形优势主从之间不需要一字节一字节地从某个position开始diff而是按事务集合补差。如果从库缺的不是连续段GTID能直接挑缺的补不需要从头扫描。这种“按集合缺什么补什么”的思路在网络波动、中途切换的场景下优势特别明显。所以我现在搭新从库的流程基本固定下来了在从库上用XtraBackup恢复一份全量备份。确认gtid_purged已包含备份时刻的GTID集合。执行三行命令CHANGE MASTER、START SLAVE、SHOW SLAVE STATUS完事。这个流程已经跑了四五年基本没出过岔子。4.3 数据修复场景部分替换时GTID的坑GTID还原不是只有全库恢复这一个场景。线上偶尔会遇到某个库或某张表的数据坏了想用备份文件里的数据单独恢复那一部分。这种情况下GTID往往会帮倒忙原因在于GTID事务是全局的不是按表切分的。假设你用mysqldump只导出了db1.t1这张表恢复时目标库的gtid_executed里已经有这张表的相关事务了。导入时如果dump文件带了SET GLOBAL.gtid_purgedMySQL会直接报错提示GTID集合有重叠或者不允许修改。即使你绕过这个限制从GTID角度来说新导入的事务ID也会和已经存在的ID重复引起一系列连锁问题。我处理这种场景的办法比较多简单说两种实用的第一种导出时不带GTID信息mysqldump \ --single-transaction \ --set-gtid-purgedOFF \ db1 t1 t1_restore.sqlmysql导入到目标库后这些事务不会被标上“新GTID”而是以普通事务方式执行。恢复本身没问题但后续如果这个库参与GTID复制要小心主从数据一致性。第二种更推荐不要直接往目标库导而是先恢复到临时实例再把数据导出成普通SQL最后导入目标库。多一层中转避免了GTID冲突数据校验也好做。5. 踩坑合集GTID恢复的脏活累活5.1 常见报错与排查GTID恢复的报错翻来覆去就那几种。我整理了个速查表你在操作时可以直接对照报错信息原因解决办法ERROR 3546 (GLOBAL.GTID_PURGED cannot be changed)目标实例gtid_executed非空不允许直接设置gtid_purged清空gtid_executed后再导入或使用全新实例ERROR 1840 (GLOBAL.GTID_PURGED can only be set when ... )gtid_executed为空时设置gtid_purged的方式不对用SET GLOBAL.gtid_purged ...而不是SET GLOBAL gtid_purgedGot fatal error 1236主库binlog被清理从库需要的GTID事务已经不存在重新做全量备份恢复Cannot replicate because the master purged required binary logs任务需要的GTID已被purge对目标实例设置正确的gtid_purged或从新备份恢复Duplicate entry for key PRIMARY导入数据时主键冲突一般是之前导入失败重试导致清空目标表后重新导入这块最需要敲黑板的是3546这个报错。很多人第一次导入GTID备份失败就是没有注意到目标库不是“全新”的。哪怕目标库是自己刚装上、什么都没导入过的MySQL只要曾经执行过开启GTID、重启、初始化这类操作gtid_executed就可能已经包含一个自动初始化的GTID集合。最稳妥的办法是导入前先执行一次SHOW GLOBAL VARIABLES LIKE gtid_executed;如果返回值是空那万事大吉。如果非空直接reset master清掉空集再导入RESET MASTER;注意RESET MASTER在从库上会清掉中继日志除非确认这个实例没有在用复制链路否则别乱执行。5.2 GTID导致的重复事务如何跳过GTID模式下主从复制不会重复执行任何已经出现在gtid_executed里的事务。这本来是好事但有个副作用当你手动往主库插入一条数据而这条数据对应的GTID恰好和从库已执行过的事务相同从库会静默跳过没有任何报错。这种场景最常见于恢复演练比如从库恢复完发现主库业务写入后从库数据对不上。排查方法比较简单在从库上执行SHOW SLAVE STATUS\G看Seconds_Behind_Master是否一直为0再看Retrieved_Gtid_Set和Executed_Gtid_Set是否一致。如果主库一直在发事务从库的Retrieved不动那就要怀疑有重复GTID被跳过了。更彻底的办法是手动注入空事务来跳过某个确切的GTIDSET GTID_NEXT3d3e5e9a-1a5a-11ef-9b3a-005056a35b5f:452346; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC;这个方法适合你已经明确知道哪个事务有问题、并且确定可以跳过的场景。千万不要在生产环境随手用跳过该执行的事务数据一致性就变成薛定谔的一致性了。5.3 小技巧迁移到新实例时如何彻底清空GTID做环境隔离或者把生产数据复制到测试环境时经常希望目标实例完全不带任何GTID痕迹以便后续重新开始一套全新的GTID序列。这种情况下RESET MASTER是最快的办法。执行前确认三件事实例不是任何复制链路的下游。实例数据已经不再需要。binlog可以全部丢弃。确认之后STOP SLAVE; RESET MASTER;RESET MASTER会把binlog索引文件和所有binlog日志清空同时把gtid_executed和gtid_purged都重置为空。之后实例会以全新的GTID序列继续工作不会和旧的事务有任何关联。这里一定要提醒一句这个操作会让所有基于binlog的增量备份失效。如果你还需要做时间点恢复别用这招。我是因为经常搭建短生命周期测试实例所以对这套清空流程特别熟但涉及生产数据时绝对不用这种激进手段。结尾这套流程跑下来的几点感受GTID模式下的备份还原我个人最大的感受是“确定性”变高了。以前用binlog position那套每次恢复完总要去核对“文件号对不对、position偏没偏”心里没有底。现在每次导入完只要看一眼gtid_executed和备份文件里的GTID集合是否一致基本就能确认恢复正确。建议所有用MySQL 5.7以上版本的同学都尽早把gtid_modeON打开。别等到需要做从库扩容或者故障切换时才临时改变更窗口小风险也高。平时养成备份后记录GTID集合的习惯恢复操作就会变得流畅且踏实。 MySQL GTID备份恢复实战：原理、流程与踩坑指南
MySQL还原备份方法3单独写GTID就是因为这个方法跟前两种完全不是一个套路。传统方式做还原要先记binlog文件名和position然后在新实例上手动指过去中间差一个事务都容易对不上。GTID方案直接把“全局唯一事务ID”这件事交给MySQL自己管备份还原时只需要关心“这个事务集合长什么样”剩下的事情数据库自动帮你排除掉已执行过的事务。这篇我把这类还原的完整流程、GTID状态怎么读、踩过的坑都捋一遍适合正在搭从库、做数据迁移或定期做恢复演练的同学参考。1. GTID到底是啥为什么备份恢复绕不开它1.1 GTID的核心原理全局唯一的事务编号GTID的全称是Global Transaction Identifier全局事务标识符。每个在GTID模式下提交的事务都会在生成时获得一个全局唯一的编号格式是UUID:sequence_number。UUID是每个MySQL实例的server_uuidsequence_number是实例内自增的序号。比如3d3e5e9a-1a5a-11ef-9b3a-005056a35b5f:1-45这一串就代表某个源实例上从第1到第45个事务。这个设计把“在哪个实例的哪个binlog位置”变成了“我是哪个实例的第几个事务”。前者是坐标后者是身份证号。在做备份和恢复这种跨实例操作时坐标会随环境变化但身份证号永远不变。所以GTID非常适合用来做数据搬运和主从对齐——只要新实例拿到同一个事务集合它就知道自己该从哪里继续。1.2 为什么备份恢复要优先考虑GTID传统基于binlog position的恢复核心难处在于position是一个动态值。备份时记下的MASTER_LOG_FILE和MASTER_LOG_POS到了新环境之后如果中途还有别的实例在写数据或者源实例做过日志清理这个坐标可能就失效了。你去目标库执行CHANGE MASTER TO的时候甚至可能因为文件被purge而直接报错。GTID模式彻底绕开了这类问题。备份文件里记录的是gtid_executed的集合恢复时只需要一句话把所有事务补齐从库再通过MASTER_AUTO_POSITION1自动协商起点不需要人工去算“现在到底该从哪个binlog的哪个position开始接”。对经常搭从库、隔三差五做全量恢复的人来说这套机制能省掉大量人为核对的时间也降低了出错概率。这也是我在MySQL 5.7之后坚持所有实例统一开启GTID的核心原因。2. 动手前先看清GTID状态三个必查参数2.1 确认GTID是否开启gtid_mode和enforce_gtid_consistency做GTID备份恢复之前第一件事不是敲备份命令而是确认源实例和目标实例的GTID模式。最多人踩的坑就是源库开着GTID目标库没开或者反过来恢复完直接报错或者复制对不上。查看命令很简单SHOW VARIABLES LIKE gtid_mode; SHOW VARIABLES LIKE enforce_gtid_consistency;gtid_mode有几个值ON、OFF、ON_PERMISSIVE、OFF_PERMISSIVE。生产环境建议直接是ON。如果还是OFF备份还原逻辑就要走传统position方式这篇讲的GTID流就不适用了。另一个参数是enforce_gtid_consistency它控制哪些语句在GTID模式下允许执行。比如CREATE TABLE ... SELECT这种非事务性语句在GTID模式下默认是被禁止的。备份还原时如果出现这类报错不是你恢复姿势错了而是这个参数在把关。细节我放到第5章的问题排查里讲。2.2 读懂gtid_executed和gtid_purgedGTID模式下每个实例都有两个状态变量理解它们还原就成功了一半。gtid_executed表示当前实例上已经执行过的事务集合可以理解为“我做过的所有事”。gtid_purged表示已经被清理掉的事务集合通常是binlog被purge之后记录下来的“我不再有完整binlog历史的事务”。这两个值的关系要记清楚gtid_purged是gtid_executed的子集。一个事务如果已经被purge它必然已经执行过但执行过的事务不一定会被purge除非日志被清理了。查询方式SHOW GLOBAL VARIABLES LIKE gtid_purged; SHOW GLOBAL VARIABLES LIKE gtid_executed;也可以直接查性能表SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME IN (gtid_executed,gtid_purged);备份还原时主要关注gtid_purged。因为从备份文件恢复数据时MySQL通过设置gtid_purged来告诉新实例“这些事务在备份文件里已经包含了日志里虽然找不到但你不用再执行了”。2.3 备份前环境检查清单老话说得好备份恢复多花三分钟检查后面少熬三个小时夜。我每次做GTID还原前都会按下面这个清单过一遍源实例gtid_modeONenforce_gtid_consistencyON。源、目标实例server_uuid不能重复。如果是克隆虚拟机镜像导致的重复uuidSHOW VARIABLES LIKE server_uuid就能发现必须提前改掉否则复制链路直接起不来。目标实例gtid_executed如果非空要想清楚是否和备份的GTID集合有重叠。重叠会导致导入时自动跳过这未必是坏事但你要心里有数。目标实例至少保证有一个同步的空数据库实例最好干净到连二进制日志都没有历史事务的那种。3. GTID下的备份实操mysqldump和XtraBackup怎么选3.1 用mysqldump做逻辑备份并保留GTID信息mysqldump做GTID备份核心参数是--set-gtid-purged。这个参数有三个值AUTO、ON、OFF。ON在dump文件里写入SET GLOBAL.gtid_purged...恢复时能让目标实例快点对齐GTID状态。OFF不写任何GTID信息适合你只想导数据、不关心GTID流转的场景。AUTO默认值只有当前实例GTID开了才会输出GTID信息。我常用的备份命令mysqldump \ --single-transaction \ --set-gtid-purgedON \ --master-data2 \ --routines --triggers --events \ --all-databases \ -u备份账号 -p /data/backup/gtid_full_$(date %F).sql这里有个细节--single-transaction配合InnoDB可以让备份基于一致性快照不加锁业务还能正常写。--master-data2会把CHANGE MASTER TO信息以注释形式写到文件里虽然GTID模式下不依赖它但作为审计信息留着没坏处。备份完成后打开文件头部你会看到一段类似下面的内容-- GTID state at the beginning of the backup SET GLOBAL.gtid_purged3d3e5e9a-1a5a-11ef-9b3a-005056a35b5f:1-452345;这行就是后续恢复时目标实例用来对齐GTID的“锚”。如果这段内容在你恢复时没有生效那从库大概率会从错误的位置开始复制导致数据不一致。3.2 用XtraBackup做物理备份并记录GTID落点mysql逻辑备份适合中小规模库到了几百GB甚至上TB的量级一遍mysqldump能跑几个小时恢复也慢。物理备份XtraBackup这时候更合适。它直接拷贝数据文件加上redo log里的增量变化能做到近乎实时的物理一致性备份。备份命令相对简单xtrabackup --backup \ --target-dir/data/backup/full \ --user备份账号 \ --passwordxxx \ --host127.0.0.1备份结束后binlog位置和GTID信息会记录在几个文件里。关键有两个xtrabackup_binlog_info记录binlog文件名、position和GTID集合。xtrabackup_info包含更完整的备份元信息比如备份开始结束时间、lsn范围、GTID状态。这两个文件一般只有几行但千万别删。用XtraBackup做恢复时目标实例的对齐依据就是它们。如果你在备份后还开了--slave-info还会多一个xtrabackup_slave_info里面记录的是从库自己的复制信息搭建级联从库时特别有用。3.3 备份文件里的GTID信息怎么读不管用哪种工具GTID备份的本质都一样把数据库恢复到某个时间点同时告诉目标实例“这个时间点对应哪些事务”。所以拿到备份后建议第一时间把GTID信息摘出来记到备注里。恢复不顺利时这个备注能帮你快速判断是备份问题还是恢复流程问题。用mysqldump的话直接grepgrep -i gtid_purged /data/backup/gtid_full_2025-01-01.sql用XtraBackup的话cat /data/backup/full/xtrabackup_binlog_info cat /data/backup/full/xtrabackup_info | grep -i gtid我以前碰到过一次备份文件是好的但恢复之后数据总差一点的情况最后发现是拿错了备份那个时间点的GTID信息导致从库追日志追到一半卡住了。所以这个“读GTID”的过程虽然只有几秒钟但在整个恢复流程里价值非常大。4. 还原与恢复GTID事务如何落库4.1 全新恢复导入备份并让GTID对齐全新环境恢复是最简单也最典型的GTID还原场景。假设你拿到一份mysqldump生成的sql文件目标库是台全新实例还没有任何业务数据。导入流程分三步。第一步确保目标实例GTID模式开启。如果没开先在配置文件里加[mysqld] gtid_modeON enforce_gtid_consistencyON然后重启MySQL。第二步导入数据mysql -uroot -p /data/backup/gtid_full_2025-01-01.sql导入时dump文件里那条SET GLOBAL.gtid_purged...会把目标实例的gtid_executed和gtid_purged都设置成备份时刻的状态。导入完再查一下SHOW GLOBAL VARIABLES LIKE gtid_executed;你会看到结果和备份文件里记录的GTID完全一致。这就代表新实例已经站在了和源实例相同的时间点上。第三步如果是搭建从库执行CHANGE MASTER TO MASTER_HOST源实例IP, MASTER_USER复制账号, MASTER_PASSWORD密码, MASTER_AUTO_POSITION1; START SLAVE;看到这里你应该明白了整个搭建过程不需要再关心binlog文件名和position。MASTER_AUTO_POSITION1会自动让源实例把主库缺失的GTID事务发给从库从库已执行过的事务自动跳过天生不会重复执行。4.2 基于GTID搭建新从库省去binlog文件名和position计算老办法搭建从库最烦的一步就是从备份文件里找MASTER_LOG_FILE和MASTER_LOG_POS这两个字段差一个数字全盘白干。GTID模式下CHANGE MASTER TO只写MASTER_AUTO_POSITION1主从协商交给数据库自己逻辑非常干净。从性能角度说GTID自动定位还有一个隐形优势主从之间不需要一字节一字节地从某个position开始diff而是按事务集合补差。如果从库缺的不是连续段GTID能直接挑缺的补不需要从头扫描。这种“按集合缺什么补什么”的思路在网络波动、中途切换的场景下优势特别明显。所以我现在搭新从库的流程基本固定下来了在从库上用XtraBackup恢复一份全量备份。确认gtid_purged已包含备份时刻的GTID集合。执行三行命令CHANGE MASTER、START SLAVE、SHOW SLAVE STATUS完事。这个流程已经跑了四五年基本没出过岔子。4.3 数据修复场景部分替换时GTID的坑GTID还原不是只有全库恢复这一个场景。线上偶尔会遇到某个库或某张表的数据坏了想用备份文件里的数据单独恢复那一部分。这种情况下GTID往往会帮倒忙原因在于GTID事务是全局的不是按表切分的。假设你用mysqldump只导出了db1.t1这张表恢复时目标库的gtid_executed里已经有这张表的相关事务了。导入时如果dump文件带了SET GLOBAL.gtid_purgedMySQL会直接报错提示GTID集合有重叠或者不允许修改。即使你绕过这个限制从GTID角度来说新导入的事务ID也会和已经存在的ID重复引起一系列连锁问题。我处理这种场景的办法比较多简单说两种实用的第一种导出时不带GTID信息mysqldump \ --single-transaction \ --set-gtid-purgedOFF \ db1 t1 t1_restore.sqlmysql导入到目标库后这些事务不会被标上“新GTID”而是以普通事务方式执行。恢复本身没问题但后续如果这个库参与GTID复制要小心主从数据一致性。第二种更推荐不要直接往目标库导而是先恢复到临时实例再把数据导出成普通SQL最后导入目标库。多一层中转避免了GTID冲突数据校验也好做。5. 踩坑合集GTID恢复的脏活累活5.1 常见报错与排查GTID恢复的报错翻来覆去就那几种。我整理了个速查表你在操作时可以直接对照报错信息原因解决办法ERROR 3546 (GLOBAL.GTID_PURGED cannot be changed)目标实例gtid_executed非空不允许直接设置gtid_purged清空gtid_executed后再导入或使用全新实例ERROR 1840 (GLOBAL.GTID_PURGED can only be set when ... )gtid_executed为空时设置gtid_purged的方式不对用SET GLOBAL.gtid_purged ...而不是SET GLOBAL gtid_purgedGot fatal error 1236主库binlog被清理从库需要的GTID事务已经不存在重新做全量备份恢复Cannot replicate because the master purged required binary logs任务需要的GTID已被purge对目标实例设置正确的gtid_purged或从新备份恢复Duplicate entry for key PRIMARY导入数据时主键冲突一般是之前导入失败重试导致清空目标表后重新导入这块最需要敲黑板的是3546这个报错。很多人第一次导入GTID备份失败就是没有注意到目标库不是“全新”的。哪怕目标库是自己刚装上、什么都没导入过的MySQL只要曾经执行过开启GTID、重启、初始化这类操作gtid_executed就可能已经包含一个自动初始化的GTID集合。最稳妥的办法是导入前先执行一次SHOW GLOBAL VARIABLES LIKE gtid_executed;如果返回值是空那万事大吉。如果非空直接reset master清掉空集再导入RESET MASTER;注意RESET MASTER在从库上会清掉中继日志除非确认这个实例没有在用复制链路否则别乱执行。5.2 GTID导致的重复事务如何跳过GTID模式下主从复制不会重复执行任何已经出现在gtid_executed里的事务。这本来是好事但有个副作用当你手动往主库插入一条数据而这条数据对应的GTID恰好和从库已执行过的事务相同从库会静默跳过没有任何报错。这种场景最常见于恢复演练比如从库恢复完发现主库业务写入后从库数据对不上。排查方法比较简单在从库上执行SHOW SLAVE STATUS\G看Seconds_Behind_Master是否一直为0再看Retrieved_Gtid_Set和Executed_Gtid_Set是否一致。如果主库一直在发事务从库的Retrieved不动那就要怀疑有重复GTID被跳过了。更彻底的办法是手动注入空事务来跳过某个确切的GTIDSET GTID_NEXT3d3e5e9a-1a5a-11ef-9b3a-005056a35b5f:452346; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC;这个方法适合你已经明确知道哪个事务有问题、并且确定可以跳过的场景。千万不要在生产环境随手用跳过该执行的事务数据一致性就变成薛定谔的一致性了。5.3 小技巧迁移到新实例时如何彻底清空GTID做环境隔离或者把生产数据复制到测试环境时经常希望目标实例完全不带任何GTID痕迹以便后续重新开始一套全新的GTID序列。这种情况下RESET MASTER是最快的办法。执行前确认三件事实例不是任何复制链路的下游。实例数据已经不再需要。binlog可以全部丢弃。确认之后STOP SLAVE; RESET MASTER;RESET MASTER会把binlog索引文件和所有binlog日志清空同时把gtid_executed和gtid_purged都重置为空。之后实例会以全新的GTID序列继续工作不会和旧的事务有任何关联。这里一定要提醒一句这个操作会让所有基于binlog的增量备份失效。如果你还需要做时间点恢复别用这招。我是因为经常搭建短生命周期测试实例所以对这套清空流程特别熟但涉及生产数据时绝对不用这种激进手段。结尾这套流程跑下来的几点感受GTID模式下的备份还原我个人最大的感受是“确定性”变高了。以前用binlog position那套每次恢复完总要去核对“文件号对不对、position偏没偏”心里没有底。现在每次导入完只要看一眼gtid_executed和备份文件里的GTID集合是否一致基本就能确认恢复正确。建议所有用MySQL 5.7以上版本的同学都尽早把gtid_modeON打开。别等到需要做从库扩容或者故障切换时才临时改变更窗口小风险也高。平时养成备份后记录GTID集合的习惯恢复操作就会变得流畅且踏实。