必须先执行stop slave，再执行reset slave all，否则报错error 1197；该命令清除连接参数、relay log及info文件，但保留gtid_executed、gtid_purged和server-id，且gtid模式下必须配合master_auto_position=1使用。
RESET SLAVE ALL 必须配合 STOP SLAVE 才能执行
直接执行 RESET SLAVE ALL 会报错 ERROR 1197 (HY000): This operation cannot be performed with a running slave。MySQL 5.7+ 强制要求先停复制，再清状态——这不是可选项，是硬性校验。
常见误操作：看到 Slave_IO_Running: Yes 还没等 STOP SLAVE 完成就敲 RESET SLAVE ALL，结果命令卡住或失败。
- 必须先执行
STOP SLAVE，等返回Query OK再继续 - 执行前用
SHOW SLAVE STATUS\G确认Seconds_Behind_Master已归零（或你接受丢弃未应用的 relay log） - 如果 SQL 线程还在追日志（
Relay_Log_Pos != Exec_Master_Log_Pos），RESET SLAVE ALL会丢弃这部分，数据可能不一致
RESET SLAVE ALL 清什么、不碰什么要分清
RESET SLAVE ALL 是“全量清除”，但不是“重置一切”。它删文件、清内存、归零延迟，但绕开 GTID 相关变量——这点容易被忽略，尤其在 GTID 模式下会导致后续 START SLAVE 失败。
- 清除项：
master.info和relay-log.info文件、所有 relay log、内存中MASTER_HOST/MASTER_USER/MASTER_PASSWORD等连接参数、MASTER_DELAY - 保留项：
gtid_executed、gtid_purged不变；server-id不受影响；已存在的数据库和表结构完全不动 - 执行后
SHOW SLAVE STATUS\G输出为空，这是正常现象，不是错误
CHANGE MASTER TO 参数必须匹配当前 GTID 模式
重置完不立刻配新主库，等于白清。但填参时若忽略 GTID 开关状态，START SLAVE 会卡在 Waiting for master to send event 或报 Client requested master to start replication from position > file size。
- 查 GTID 是否开启：
SELECT @@gtid_mode;返回ON就必须用MASTER_AUTO_POSITION = 1 - GTID 场景示例：
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION = 1; - 非 GTID 场景才填
MASTER_LOG_FILE和MASTER_LOG_POS，且这两个值必须来自主库当前SHOW MASTER STATUS，不能沿用旧快照
主库上清理复制用户权限常被遗漏
从库执行 RESET SLAVE ALL 只清本地状态，主库上的复制账号、权限、SSL 配置仍存在。如果不清理，可能被误连、产生冗余连接或安全风险。
- 查复制用户：
SELECT user, host FROM mysql.user WHERE Repl_slave_priv = 'Y'; - 回收权限：
REVOKE REPLICATION SLAVE ON *.* FROM 'repl'@'192.168.1.%'; - 删用户（谨慎）：
DROP USER 'repl'@'192.168.1.%'; - 注意：如果主库还连着其他从库，只 revoke 对应 host，别误删全局复制账号
真正干净的重置，不是只跑一条 RESET SLAVE ALL。它依赖 STOP/RESET/CHANGE/START 四步闭环，且每步都受 GTID、锁状态、权限残留影响。最容易出问题的地方，往往在你以为“已经清完了”的那个间隙——比如忘记 UNLOCK TABLES 后主库 binlog 已滚动，或者 CHANGE MASTER TO 里漏了 MASTER_AUTO_POSITION = 1。
