必须用 RESET MASTER 清空 gtid_executed 和 gtid_purged，因为 RESET REPLICA ALL 仅重置复制通道状态（如IO/SQL线程、relay log、master info表等），完全不修改 gtid_executed、gtid_purged 全局变量及 mysql.gtid_executed 表，无法清除GTID执行历史。
必须用 RESET MASTER 清空 gtid_executed 和 gtid_purged，而不是 RESET REPLICA ALL —— 后者只清复制通道状态，不碰 GTID 执行历史。
为什么 RESET REPLICA ALL 不能重置 GTID 执行记录
RESET REPLICA ALL 的作用范围很明确：停线程、删 slave_master_info/slave_relay_log_info 表、清 relay log 文件、重置 IO/SQL 状态字段。但它完全不修改 gtid_executed 或 gtid_purged 这两个全局变量，也不清空 mysql.gtid_executed 表。
常见误操作现象：
- 执行完
RESET REPLICA ALL后，SELECT @@global.gtid_executed;依然返回旧值 - 后续
CHANGE REPLICATION SOURCE TO ... SOURCE_AUTO_POSITION=1失败，报错ERROR 3077或同步卡在Retrieved_Gtid_Set为空 - 从库自己执行过写入（比如误
INSERT），Executed_Gtid_Set已污染，但RESET REPLICA ALL对它毫无影响
RESET MASTER 实际做了什么
这是 MySQL 中唯一能彻底重置 GTID 执行历史的命令，但它有强前提：仅限从库且确认不是主库（即不对外提供 binlog 复制服务）。
执行后立即发生：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 清空
mysql.gtid_executed表（该表从 MySQL 5.7.6 起存在） - 将
@@global.gtid_executed设为空集合（''） - 将
@@global.gtid_purged设为与gtid_executed相同值（即也清空） - 删除所有 binlog 文件（
binlog.000001等），并重建第一个 binlog
⚠️ 注意：RESET MASTER 不影响已有数据表，但会丢失所有 binlog 历史 —— 所以只应在从库重做、且不承担主库角色时使用。
GTID 重置后的必要校验步骤
光执行命令不够，必须验证关键变量是否真正归零：
- 运行
SELECT @@global.gtid_mode, @@global.enforce_gtid_consistency;，确保都为ON；否则START REPLICA会静默失败 - 检查
SELECT @@global.gtid_executed;返回结果应为''（空字符串），不是NULL或残留集合 - 执行
SHOW REPLICA STATUS\G，确认Retrieved_Gtid_Set和Executed_Gtid_Set都为空；若后者非空，说明RESET MASTER没生效或被跳过 - 若之前手动写入过数据，
RESET MASTER后仍需人工清理脏数据，否则START REPLICA会因主键冲突再次中断
最常被忽略的一点：RESET MASTER 和 RESET REPLICA ALL 是互补而非替代关系。重做从库时，通常要先 STOP REPLICA，再 RESET REPLICA ALL 清通道，再 RESET MASTER 清 GTID，最后才 CHANGE REPLICATION SOURCE TO。漏掉任一环，GTID 状态就可能错位，且这种错位不会立刻报错，而是在后续某次事务应用时突然爆发。
