ERROR 3546是MySQL阻止将gtid_purged设为子集的保护机制，因gtid_purged只能扩大不可缩小；常见于dump恢复、主从GTID不一致等场景，修复须确保新值为旧值超集，否则需重建从库。
ERROR 3546：不能把 gtid_purged 设成子集
这个错误不是权限或语法问题，而是 MySQL 在阻止你“说谎”——gtid_purged 表示哪些事务的日志已被永久删除，一旦写入，只能扩大（加新 GTID），不能缩小（删旧 GTID）。如果你执行了类似 SET GLOBAL gtid_purged = 'xxx:1-50'，而当前值是 'xxx:1-100'，MySQL 就会直接拒绝并报 ERROR 3546。
常见触发场景：
- 用
mysqldump恢复从库时加了--set-gtid-purged=ON，但 dump 文件里的gtid_purged比目标实例当前的还小 - 手动重建从库后，误用旧备份的
gtid_purged值覆盖新实例 - 主库执行过
RESET MASTER，但没同步更新从库的复制起点
检查当前 gtid_purged 和 gtid_executed 状态
先确认到底差在哪，别急着改：
SELECT @@global.gtid_executed, @@global.gtid_purged;
再对比主库的 SHOW MASTER STATUS\G 输出中的 Executed_Gtid_Set。关键看三点：
- 从库的
gtid_purged是否包含主库已 purge 的全部 GTID？如果不含，说明从库“记忆”不全，后续拉日志可能失败 - 从库
gtid_executed是否严格 ⊆ 主库Executed_Gtid_Set？如果超出了，说明从库多执行了某些事务（比如人为注入过空事务但没清理上下文） - 主库
SELECT @@gtid_purged返回值里，是否包含从库当前gtid_executed的全部？如果不含，意味着主库日志已丢，从库无法追平
安全修复：只允许追加，不许回退
修复的核心原则是：新 gtid_purged 必须是旧值的超集（即并集）。操作分两步：
第一步，获取主库当前完整的已 purge 集合：
SELECT @@global.gtid_purged AS master_purged;
第二步，在从库上安全设置（注意用 UNION 计算并集，不是直接覆盖）：
SET GLOBAL gtid_purged = '旧值,新值'; -- 格式如 'aaa:1-100,bbb:1-50'
或者更稳妥地用字符串拼接（确保无重复、无遗漏）：
SET GLOBAL gtid_purged = CONCAT(@@global.gtid_purged, ',', '新GTID集合');
⚠️ 绝对禁止的操作：
-
RESET MASTER—— 它会清空gtid_executed和gtid_purged，让从库“失忆”，后续CHANGE MASTER TO ... MASTER_AUTO_POSITION=1必然失败 - 用
mysqldump --set-gtid-purged=ON导出后再导入到已有 GTID 状态的实例 —— dump 文件自带的SET @@GLOBAL.GTID_PURGED语句大概率冲突 - 在从库上执行
SET GLOBAL gtid_purged = '某个子集'—— MySQL 会立刻报错且拒绝执行
什么时候必须重建从库，而不是修 gtid_purged
如果发现以下任一情况，跳过错误或修补 gtid_purged 已无意义，数据一致性风险极高：
- 从库的
Retrieved_Gtid_Set明显大于Executed_Gtid_Set（relay log 断层，已丢失部分事务） - 主库
gtid_purged不包含从库Executed_Gtid_Set中的任意一段（说明主库 binlog 已不可逆丢失） - 从库出现
Last_Errno: 1146（表不存在）或Last_Errno: 1010（库删失败）—— DDL 执行顺序已乱，空事务跳过无效 - 曾执行过
RESET MASTER或手动清空过gtid_executed—— 全局 GTID 状态已被污染，无法可靠推导执行历史
这种情况下，gtid_purged 的值本身已失去参考价值，强行“修”只是掩盖问题。最稳的方式是停写、全量重搭从库，并确保 dump 时用 --set-gtid-purged=OFF 或手动剥离 SET 语句。
