确认复制用户插件不匹配需先查主库：执行select user, host, plugin from mysql.user where user = 'repl_user'，若plugin为caching_sha2_password且从库last_io_error含“authentication requires secure connection”，问题即锁定；再用alter user 'repl_user'@'host' identified with mysql_native_password by 'password'并flush privileges解决。
怎么确认是复制用户插件不匹配
别猜，先查主库。用 root 登录后执行：SELECT user, host, plugin FROM mysql.user WHERE user = 'repl_user';（把 repl_user 换成你实际的复制账号名）。如果 plugin 列返回 caching_sha2_password，再看从库执行 SHOW REPLICA STATUS\G 的输出里 Last_IO_Error 是否含 Authentication requires secure connection 或 caching_sha2_password cannot be loaded —— 两者同时成立，问题就锁死了。
注意：repl_user@'%' 和 repl_user@'192.168.1.10' 是两个独立账号，必须查准 host 再操作，漏一个都同步不了。
ALTER USER 必须带 host、密码和 FLUSH PRIVILEGES
在主库执行这条语句时，三个要素缺一不可：
-
ALTER USER 'repl_user'@'192.168.1.10' IDENTIFIED WITH mysql_native_password BY 'your_actual_password';——@'host'必须写全，不能省；BY 'your_actual_password'必须显式写出，否则密码被清空，从库立刻连不上 - 执行完立刻跟
FLUSH PRIVILEGES;，否则内存缓存不更新，变更无效 - 宝塔、phpEnv 等面板环境，改完还得手动重启 MySQL 服务，否则从库 IO 线程可能仍缓存旧状态
为什么改 my.cnf 的 default_authentication_plugin 不起作用
default_authentication_plugin = mysql_native_password 只影响「之后新建的用户」，对已存在的复制用户完全无效。很多人改完配置、重启 MySQL，发现 repl_user 的 plugin 字段还是 caching_sha2_password，就是因为这个配置根本不碰存量用户元数据。
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
云数据库（如阿里云 RDS）通常禁止修改 /etc/my.cnf，这条路根本走不通，ALTER USER 是唯一入口。
get_master_public_key=1 是更轻量的替代方案
如果你不想降级认证强度，可以优先尝试这个参数。停掉从库复制：STOP SLAVE;，然后重新执行：CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1;（注意全大写、MySQL 8.0.4+ 才支持）。
它会主动向主库请求 RSA 公钥，绕过握手失败，且不改动主库任何配置。但前提是主库已生成密钥对（sha256_password_private_key.pem 等），且从库客户端版本 ≥8.0.4。老版本从库（如 5.7）不识别该参数，会报 Unknown system variable 'get_master_public_key'，此时只能切回 mysql_native_password。
最容易被忽略的是 host 写错或漏掉——比如 Navicat 默认走 127.0.0.1，但你只改了 'repl_user'@'localhost'；还有密码里含 @ 或 /，被 URL 解析吃掉导致连接失败。
