复制账号鉴权失败主因是主库账号权限缺失、认证插件不兼容（如caching_sha2_password）、密码未同步或host不匹配；需查权限、插件、密码及host，执行grant、alter user、change master to并flush privileges。
复制账号频繁鉴权失败，基本可以断定是主库账号状态、认证方式或密码传递链路出了问题，不是网络不通，也不是从库配置写错了端口——Last_IO_Error里反复出现 Access denied for user 'repl'@'xxx' 或 Authentication plugin 'caching_sha2_password' cannot be loaded 就是铁证。
主库账号存在但没给 REPLICATION SLAVE 权限
很多团队建了 repl 用户就以为完事，其实 MySQL 8.0+ 默认只给 USAGE 权限，不显式 GRANT REPLICATION SLAVE ON *.*，账号根本没法被从库用来拉 binlog。
- 先查权限：
SHOW GRANTS FOR 'repl'@'%';—— 如果只返回GRANT USAGE ON *.* TO 'repl'@'%'，说明权限缺失 - 补授权必须带
ON *.*（不能限定库）：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; - 别漏掉
FLUSH PRIVILEGES;，否则权限不生效 - 注意：如果用的是 MySQL 8.0.27+，
CHANGE MASTER TO ... MASTER_PASSWORD=...已被弃用，改用GET_MASTER_PUBLIC_KEY=1+ 客户端支持密钥交换
MySQL 8.0+ 的 caching_sha2_password 插件导致密码无法解析
这是生产环境最隐蔽的坑：主库创建账号时用了默认插件，但从库客户端（尤其老版本 mysql-client 或某些连接池）不支持该插件，连认证握手都过不去。
- 确认主库账号用的什么插件：
SELECT plugin FROM mysql.user WHERE user = 'repl';—— 返回caching_sha2_password就是它 - 临时解法（仅测试）：在主库重建账号，强制指定旧插件：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 长期方案：升级从库客户端或中间件驱动，确保支持
caching_sha2_password；或统一在主库用mysql_native_password（需评估安全策略） - 注意：改插件后必须重连，已建立的连接不会自动切换认证方式
从库 CHANGE MASTER TO 中的密码与主库实际密码不一致
看似低级，实则高频：DBA 在主库改了密码，忘了同步更新从库的 CHANGE MASTER TO 配置；或者复制账号密码里有特殊字符（如 @、/、%），没做 URL 编码直接填进命令，导致实际传过去的密码被截断或解析错误。
- 检查当前配置：
SELECT MASTER_USER, MASTER_PASSWORD FROM performance_schema.replication_connection_configuration;（MySQL 8.0.22+）或看SHOW SLAVE STATUS\G里的Master_User字段（密码不显示，但可比对用户） - 重设密码时务必用单引号包裹，并转义特殊字符：
CHANGE MASTER TO MASTER_PASSWORD='p@ss%w0rd'; - 如果用的是 MySQL 8.0.27+，必须删掉
MASTER_PASSWORD参数，改用USER='repl', PASSWORD='xxx'方式（需要配套启用GET_MASTER_PUBLIC_KEY=1） - 执行完
CHANGE MASTER TO后，一定要START SLAVE;，否则新配置不生效
账号 host 匹配失败：'repl'@'%' 不等于 'repl'@'192.168.10.%'
MySQL 权限校验是精确匹配 user@host 的。从库发起连接时用的是自己的 IP（比如 192.168.10.45），但如果主库只建了 'repl'@'192.168.10.%'，而没建 'repl'@'%'，就会因 host 不匹配拒绝登录。
- 查主库所有匹配账号：
SELECT user, host FROM mysql.user WHERE user = 'repl'; - 推荐建宽泛 host：
'repl'@'%'（生产环境需配合防火墙限制源 IP） - 如果必须限定网段，确保从库真实出口 IP 落在范围内，且注意 DNS 反查可能把 IP 解析成域名，导致匹配
'repl'@'db-slave-01.example.com'失败 - 测试连通性别只用
telnet，要用mysql -h master-ip -u repl -p实际走一遍鉴权流程
真正麻烦的不是某一次连不上，而是账号在主库被反复重建、插件被来回切换、密码在不同配置文件里存了多个版本——最终从库连上又断，断了又连，日志里全是 Access denied。盯住 SHOW SLAVE STATUS\G 里的 Last_IO_Error，它从不撒谎，只是需要你逐字读清楚错在哪一环。
