最关键的一步是确认主库复制用户的认证插件是否为 caching_sha2_password；若确为该插件且从库为 mysql 5.7 或未启用 ssl/rsa，则大概率导致认证失败，应执行 alter user ... identified with mysql_native_password 切换插件并重设密码。
确认主库复制用户的认证插件是否为 caching_sha2_password
这是最关键的一步，别跳过。直接登录主库执行：
SELECT user, host, plugin FROM mysql.user WHERE user = 'repl_user';
如果 plugin 列返回的是 caching_sha2_password，且你的从库是 MySQL 5.7、旧版 Docker 镜像、或未启用 SSL/RSA 公钥机制，那基本就是它了。注意：不是所有 Last_IO_Error 都源于此，但只要错误信息里带 Authentication requires secure connection，90% 是这个插件在作祟。
用 ALTER USER ... IDENTIFIED WITH mysql_native_password 切换认证方式
这是最常用、见效最快、兼容性最强的解法，适用于绝大多数非加密内网环境。操作前确保你有主库 root 或高权限账号：
- 执行命令时必须显式指定
BY子句，即使密码不变也要重输一次，否则会报错 - 示例：
ALTER USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_actual_password';
- 改完立刻生效，无需重启 MySQL 服务
- 如果用户 host 是具体 IP（如
'repl_user'@'192.168.1.50'），ALTER USER中的 host 必须完全一致，不能写成%
为什么不用强制 SSL 方案？哪些场景才该考虑它
官方推荐走 MASTER_SSL=1 + CA 证书这条路，但它实际落地成本远高于插件切换：
- 你需要在主库生成并分发
ca.pem、server-cert.pem、server-key.pem，还要确保从库能读取到这些文件路径（比如/etc/mysql/ca.pem） - 从库执行
CHANGE MASTER TO时必须补全全部 SSL 参数，漏一个（比如MASTER_SSL_CA）就会连接失败 - 某些云数据库（如阿里云 RDS）不开放证书文件导出权限，这条路直接堵死
- 如果你的主从都在内网、流量不经过公网、且已有网络层隔离，SSL 带来的安全增益有限，反而增加维护负担
改完插件后仍连不上？检查这几个隐藏点
插件切对了，不代表万事大吉。常见漏掉的环节：
-
FLUSH PRIVILEGES;不需要执行——ALTER USER已自动刷新权限表 - 从库执行
START SLAVE;前，务必先STOP SLAVE;，否则旧连接状态可能缓存失败原因 - 检查从库的
my.cnf是否设置了default_authentication_plugin=mysql_native_password—— 这个配置只影响新创建用户，对已存在的复制用户无作用，别被它误导 - 某些老旧客户端库（如 RMySQL ≤ 1.0.0 或 mysql-connector-java 5.x）即使主库插件改了，也可能因驱动自身限制报错，此时需升级驱动版本
真正麻烦的从来不是改哪条 SQL，而是改完之后忘记检查从库是否真的用上了新凭证——SHOW SLAVE STATUS\G 里的 Seconds_Behind_Master 变成数字前，一定要盯住 Last_IO_Error 是否清空。
