必须用 reset slave all，因为 mysql 8.0 默认按通道管理复制状态，reset slave 仅重置默认通道，无法清除命名通道、gtid 位置、relay log 文件及 master/relay log info 元数据，易导致 change master to 失败或 show slave status 显示旧配置。
必须用 RESET SLAVE ALL，RESET SLAVE 不够用
MySQL 8.0 默认按通道（channel）管理复制状态，哪怕你只配了一个主库，内部也视为默认通道 ''。而 RESET SLAVE 只清空这个默认通道；其他可能残留的命名通道（比如之前试过多源复制留下的 channel_1）或 GTID 元数据不会动。结果就是：执行完 SHOW SLAVE STATUS\G 还能看到旧的 Master_Host，后续 CHANGE MASTER TO 直接报错 ERROR 3077 (HY000): Cannot change the 'MASTER_BIND' option when a channel is running。
执行前必须确认的三件事
漏掉任意一项都可能导致从库无法恢复复制，甚至丢数据：
- 从库上没有运行中的复制线程：先手动执行
STOP SLAVE;，否则RESET SLAVE ALL会报错 - 主库当前 binlog 位点已记录：在主库运行
SHOW MASTER STATUS;，记下File和Position（或整个Executed_Gtid_Set），重置后靠这个重新配置 - GTID 模式已对齐：如果要用
MASTER_AUTO_POSITION=1，主从都得确认gtid_mode=ON且enforce_gtid_consistency=ON，否则CHANGE MASTER TO会失败
UUID 冲突时不能只改 auto.cnf
看到 Last_IO_Error 含 "equal MySQL server UUIDs"、Last_IO_Errno 是 13117 或 1593，基本就是 server_uuid 重复了。但只改 auto.cnf 文件远远不够：
- 必须先停服务：
systemctl stop mysql（Docker 环境用docker stop） - 找到真实生效的
auto.cnf：查SELECT @@datadir;，再进对应路径修改，别依赖find / -name auto.cnf找到的多个结果 - 覆盖写入新 UUID：
echo "server-uuid=$(uuidgen)" > /var/lib/mysql/auto.cnf，切勿手写、切勿清空文件 - 重启后立刻执行
STOP SLAVE; RESET SLAVE ALL;——旧 UUID 已缓存在 relay log 和复制线程里，不重置就还会连错
Docker 环境下 auto.cnf 修改常失效
容器重启后 server_uuid 恢复原样？大概率是镜像自带 auto.cnf，或者挂载卷把宿主机旧文件又映射进来了。验证方式：启动容器后立刻对比 mysql -e "SELECT @@server_uuid;" 和 cat /var/lib/mysql/auto.cnf 是否一致。不一致说明文件被覆盖。
解决办法只有两个：
- 在宿主机映射目录里提前用
docker cp替换掉auto.cnf - 改用初始化脚本：容器首次启动时检测
auto.cnf是否为空或无效，自动调用uuidgen生成并写入——不能依赖镜像内置的固定值
真正容易被忽略的是：重置元数据只是第一步，后续 CHANGE MASTER TO 的参数是否匹配当前主库状态（尤其是 GTID 是否开启、binlog 格式是否为 ROW），决定了复制能不能真正跑起来。别急着 START SLAVE，先 SHOW SLAVE STATUS\G 看两行：Slave_IO_Running 和 Slave_SQL_Running 都是 Yes 才算过关。
