如何解决MySQL 8.0物理迁移后的复制认证失败_修改默认身份验证插件-mysql教程-PHP中文网

直接修改主库复制用户插件为mysql_native_password是最快速有效的解法，需先确认repl_user的plugin为caching_sha2_password且从库报“authentication requires secure connection”，再用alter user指定完整host和密码切换插件并flush privileges，最后在从库stop/start slave。

如何解决mysql 8.0物理迁移后的复制认证失败_修改默认身份验证插件

直接改插件是最快速有效的解法，前提是你的主从环境不强制要求 SSL 连接。

确认是不是 caching_sha2_password 在作祟

别猜，先查。登录主库，执行：

SELECT user, host, plugin FROM mysql.user WHERE user = 'repl_user';

如果 plugin 列返回 caching_sha2_password，且从库的 Last_IO_Error 里带 “Authentication requires secure connection”，那基本锁死问题根源。注意：不是所有 caching_sha2_password 错误都必须改插件——如果主库已配好 RSA 公钥、从库客户端支持 get_master_public_key=1，也可以走安全路径，但多数物理迁移场景下，改插件更可控。

ALTER USER 切换插件要带完整 host 和密码

MySQL 对用户是 user@host 组合唯一识别的，漏掉 host 或写错（比如用了 % 而实际连接用的是 IP），会导致改了白改。正确操作是：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

先查准复制用户的完整定义：SELECT user, host FROM mysql.user WHERE user = 'repl_user';

再执行切换（以 repl_user@'192.168.1.%' 为例）：

ALTER USER 'repl_user'@'192.168.1.%' IDENTIFIED WITH mysql_native_password BY 'your_actual_password';

立刻刷新权限：FLUSH PRIVILEGES;

不要省略 BY 'your_actual_password' —— MySQL 8.0+ 的 ALTER USER ... IDENTIFIED WITH 语法不保留原密码，不显式指定就会清空密码，导致从库连不上。

从库侧不需要改配置，但得重启 IO 线程

插件切换只在主库生效，从库不用动任何配置文件或用户定义。但旧的连接可能还缓存着失败状态，所以必须手动干预：

在从库执行：STOP SLAVE;
等几秒再启动：START SLAVE;
立刻检查：SHOW SLAVE STATUS\G，重点关注 Slave_IO_Running: Yes 和 Last_IO_Error: 是否为空

如果仍报错，大概率是主库上 ALTER USER 没命中真实连接的 host，或者密码输错了。这时候回过头再核对一次 SELECT user, host, plugin 的输出，比重试十遍更有用。

最常被忽略的一点：物理迁移后，主库的 mysql.user 表可能直接从旧实例拷贝过来，里面混着不同版本的插件记录，而 repl_user 很可能根本没被重建过——它只是“存在”，但认证逻辑已经不匹配当前 MySQL 8.0 的默认行为。所以不要假设用户配置“看起来一样”就一定可用。