error 3546的根本原因是gtid_executed与备份中gtid_purged重叠，导致mysql为防事务重复或跳变而拒绝导入；reset master虽能清空gtid状态绕过冲突，但会破坏复制链路，仅适用于全新实例；最稳妥方案是删除备份文件中的set gtid_purged语句，避免强行覆盖，确保gtid自然融入当前执行集。
导入备份时遇到 ERROR 3546 (HY000)，根本原因是目标实例的 GTID_EXECUTED 和备份文件中声明的 GTID_PURGED 有重叠 —— MySQL 拒绝执行可能造成事务重复或跳变的操作。
为什么 RESET MASTER 能“解决”但很危险
执行 RESET MASTER 会清空 gtid_executed、gtid_purged 和所有 binlog 文件，让实例“假装自己从零开始”。此时再导入含 SET @@GLOBAL.GTID_PURGED=... 的备份，就不会触发冲突。
- 仅适用于全新实例，或你确认该库无任何线上数据、无从库、无备份链路
- 若该实例已是主库或参与 MGR/主从，
RESET MASTER会导致整个复制关系断裂，下游无法继续同步 - 即使只是临时恢复测试库，也建议先
mysqldump --no-data备份当前mysql.gtid_executed表（如果存在）或记录SHOW GLOBAL VARIABLES LIKE 'gtid_executed';结果
为什么修改备份文件比关 GTID 更稳妥
真正安全的做法不是“关 GTID”，而是让备份不带 GTID 声明 —— 因为 GTID 本身是开启状态，只是备份里那行 SET @@GLOBAL.GTID_PURGED=... 在导入时强行覆盖了当前值。
- 用
sed -i '/GTID_PURGED/d' backup.sql删除该行，或手动注释掉，是最轻量、可逆的操作 - 导入后，MySQL 会基于实际执行的语句自动生成新的 GTID，自然融入当前
gtid_executed集合 - 相比
--set-gtid-purged=OFF，直接删行更可靠：某些旧版 mysqldump 在--set-gtid-purged=OFF下仍可能漏写SQL_LOG_BIN=0，导致主从丢失变更
--set-gtid-purged=OFF 不等于“关闭 GTID”
这个参数只控制备份文件是否包含 GTID 元信息，和实例本身的 gtid_mode 无关。实例仍是 GTID 模式，只是导入时不强求对齐历史。
- 下次备份务必加
--set-gtid-purged=OFF，尤其当目标库不是空库、或要导入到从库时 - 注意：若备份含
--master-data=2，它默认启用--set-gtid-purged=ON，必须显式覆盖 - 验证备份文件是否干净：导入前
head -20 backup.sql | grep -i gtid，应无输出
最易被忽略的一点：哪怕你用了 --set-gtid-purged=OFF，如果备份过程中目标库有并发写入，导入后 gtid_executed 仍可能和主库不一致 —— GTID 同步不是靠“备份那一刻的快照”，而是靠后续 binlog 流持续追平。所以恢复后务必检查 SHOW SLAVE STATUS\G 中的 Executed_Gtid_Set 是否最终收敛。
