change replication source to 报错主要分三类：认证插件不匹配（如caching_sha2_password）、网络不通（如docker内无法访问主库）、gtid或位点状态异常（如error 3021或retrieved_gtid_set为空）；定位须先查show replica status\g的last_io_error及select @@gtid_mode等关键状态。
CHANGE REPLICATION SOURCE TO 报错：常见错误类型与定位方法
报错本身不是问题，而是线索。MySQL 8.0 中 CHANGE REPLICATION SOURCE TO 失败，90% 以上可归因于三类硬性不匹配：认证插件、网络连通性、复制位点状态。别急着重试，先看 SHOW REPLICA STATUS\G 输出里的 Last_IO_Error 字段——它直接告诉你卡在哪。
典型错误信息包括：
-
Plugin caching_sha2_password could not be loaded→ 主库复制用户认证插件不兼容 -
Can't connect to MySQL server on 'mysql-master' (115)→ 从库无法访问主库端口，通常是 Docker 网络或 bind-address 配置错误 -
This operation cannot be performed with a running replication thread→ 没执行STOP REPLICA就直接改配置 -
Client requested master to start replication from position > file size→SOURCE_LOG_POS值超出主库当前 binlog 文件实际长度
为什么 ALTER USER 切换插件后仍报错？
很多用户执行了 ALTER USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES;，但从库还是连不上。原因往往藏在细节里：
- @ 后的 host 必须完全一致：主库上
'repl_user'@'172.20.0.%'和'repl_user'@'%'是两个账号，查SELECT user, host, plugin FROM mysql.user WHERE user = 'repl_user';确认实际匹配的是哪个 - 密码必须显式重写：哪怕没改密码，
BY 'xxx'也不能省略，漏掉会导致密码被清空 - 宝塔、phpEnv 等面板环境需手动重启 MySQL 服务，否则 mysqld 进程仍缓存旧用户状态
- 云数据库（如阿里云 RDS）不支持
ALTER USER ... IDENTIFIED WITH，只能通过控制台重置账号认证方式
Docker 环境下 network 和 bind-address 的致命组合
本地能 mysql -h mysql-master -P 3306 -u repl -p 连上，但从库执行 CHANGE REPLICATION SOURCE TO 就报连接超时？大概率是容器监听地址没对。
- 主库容器必须禁用
bind-address（即配置文件里不要写它，或设为0.0.0.0），否则只监听127.0.0.1，Docker 内部网络不可达 - 所有服务必须共用一个自定义 bridge 网络（如
mysql-net），不能依赖默认bridge；docker-compose.yml中每个 service 都要声明networks: [mysql-net] - 从库
SOURCE_HOST必须填主库的服务名（如mysql-master），不能填localhost、127.0.0.1或宿主机 IP - 验证连通性：进从库容器执行
ping mysql-master和telnet mysql-master 3306（需装 telnet），两项都通才继续
报错 ERROR 3021 或 Retrieved_Gtid_Set 为空？GTID 状态没清理干净
主从切换后重建复制关系，或重装从库时，常遇到 ERROR 3021 或 Retrieved_Gtid_Set 为空、Executed_Gtid_Set 却有值。这不是语法错，是 GTID 元数据冲突。
- 必须先执行
STOP REPLICA;，再RESET REPLICA ALL;（MySQL 8.0.22+），彻底清空 relay log、master info、gtid_executed 等全部状态 - 确认两边
gtid_mode=ON且enforce_gtid_consistency=ON，用SELECT @@gtid_mode, @@enforce_gtid_consistency;查 - 若新主库启用了
source_auto_position=1，从库CHANGE REPLICATION SOURCE TO也必须带SOURCE_AUTO_POSITION=1，否则即使位置对也会拒绝同步 -
Retrieved_Gtid_Set为空但Executed_Gtid_Set有值，说明从库自己执行过事务（比如误写了数据），此时需先RESET MASTER;清空本地 GTID 日志，再重新拉取
真正卡住的点，往往不在命令怎么写，而在主库 binlog 是否真在跑、复制用户是否真能被从库用那个 host 认证、GTID 状态是否被残留事务污染。每次报错，盯住 Last_IO_Error 和 SELECT @@gtid_mode 这两行输出，比重配一遍快得多。
