主从复制中断根本原因是caching_sha2_password在非加密连接下拒绝握手，需先用SELECT和SHOW确认复制用户插件及默认配置，再用ALTER USER显式切换为mysql_native_password并FLUSH PRIVILEGES。
主从复制中断根本不是配置没 reload 或密码错了，而是 caching_sha2_password 在非加密连接下拒绝握手——必须明确解决认证协议不匹配，而不是反复重试 START SLAVE。
查清从库连的是哪个主库用户及其认证插件
从库 IO 线程失败时，Last_IO_Error 里出现 Authentication requires secure connection 就是典型信号。但别急着改配置，先确认问题源头：
- 登录主库，执行
SELECT user, host, plugin FROM mysql.user WHERE user = 'repl';—— 注意替换repl为你实际的复制账号名 - 如果
plugin是caching_sha2_password，且从库没开 SSL，那这就是唯一瓶颈 - 特别注意：主库上
'repl'@'%'和'repl'@'192.168.1.10'是不同记录，必须查准从库连接时用的host值
ALTER USER 切换复制账号的认证插件（最常用且安全）
这是绝大多数生产环境首选方案，不影响其他用户，也不依赖重启或全局配置变更：
- 在主库上执行：
ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_repl_password'; - 务必带上密码（
BY子句），否则会清空密码导致从库永久失联 - 如果从库是用具体 IP 连接（比如
CHANGE MASTER TO MASTER_HOST='192.168.1.10'），则要同步改对应host：ALTER USER 'repl'@'192.168.1.10' IDENTIFIED WITH mysql_native_password BY 'your_repl_password'; - 执行
FLUSH PRIVILEGES;—— 虽然多数情况自动生效，但某些版本（尤其云 RDS）必须显式刷新才更新内存权限缓存
MySQL 8.4+ 环境下 mysql_native_password 插件被禁用怎么办
如果你用的是 MySQL 8.4 或更高版本，执行 ALTER USER ... IDENTIFIED WITH mysql_native_password 报错 Plugin 'mysql_native_password' is not loaded，说明插件已被默认关闭：
- 编辑
my.cnf，在[mysqld]段添加：mysql_native_password=ON - MySQL 8.4+ 已弃用
default_authentication_plugin，不要写它；若需兼容新老用户混合场景，可加authentication_policy=mysql_native_password - 重启 MySQL：
systemctl restart mysqld（Linux）或net stop MySQL && net start MySQL（Windows） - 重启后立刻再执行
ALTER USER命令，此时插件已加载，命令可成功
为什么改 default_authentication_plugin 配置无效
很多人改完 my.cnf 重启，发现从库还是连不上——因为这个配置只影响新建用户，对已存在的 repl 用户完全无作用：
-
default_authentication_plugin仅决定CREATE USER不指定IDENTIFIED WITH时的默认值 - 已有用户的
plugin字段存储在mysql.user表中，不会因配置变更而自动更新 - 云数据库（如阿里云 RDS、腾讯云 CDB）通常禁止修改
my.cnf，这条路根本走不通，只能靠ALTER USER - 即使本地能改配置，也得记得：改完只是“未来用户”用旧插件，当前故障用户仍需单独处理
真正容易被忽略的点是：主库改完用户插件后，从库必须执行 STOP SLAVE; START SLAVE; 才会重新发起握手；有些运维习惯只跑 START SLAVE，但 IO 线程卡在错误状态时，START SLAVE 不会重试连接，必须先 STOP 再 START。
