优先尝试加 get_master_public_key=1 参数，它不改主库配置、不降安全等级，可解决因缺失RSA公钥导致的caching_sha2_password握手失败问题。
直接改 caching_sha2_password 插件不是必须的，优先试试加 get_master_public_key=1 参数——它不改主库配置、不降安全等级，且多数情况下就能解决。
为什么 Last_IO_Error 显示 caching_sha2_password 认证失败
这不是插件“坏了”，而是认证流程卡在握手阶段：主库用 caching_sha2_password，但没开 SSL，又没提供 RSA 公钥，从库 IO 线程就拒绝连接。错误里出现 Authentication requires secure connection 就是典型信号。
常见触发场景包括：
- 主库未配置 SSL 证书，也未生成 RSA 密钥对（
sha256_password_private_key.pem等） - 从库 MySQL 客户端版本较旧（如 5.7 或某些 Docker 镜像内置客户端），不支持公钥请求机制
- 网络中间设备（如代理、防火墙）拦截了额外的公钥交换包
change master to 时加 get_master_public_key=1 怎么用
这是最轻量、影响最小的修复方式，只改从库配置，主库完全不动。
操作前先停复制：
STOP SLAVE;
然后重新执行 CHANGE MASTER TO，关键是要带上 get_master_public_key=1：
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, GET_MASTER_PUBLIC_KEY=1;
注意几点：
-
GET_MASTER_PUBLIC_KEY=1必须大写，MySQL 8.0.4+ 才正式支持该语法 - 如果主库已启用 SSL，这个参数会被忽略；没启用时它会主动向主库发起公钥拉取请求
- 部分老版本从库（如 MySQL 5.7）不识别该参数，会报错
Unknown system variable 'get_master_public_key'，此时只能退到插件切换方案
真要切回 mysql_native_password，用户级修改比全局配置更安全
全局改 default_authentication_plugin 会影响所有新建用户，包括未来可能接入的监控、备份工具，容易埋兼容性雷。
推荐只针对复制用户单独切插件：
ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
执行后立即生效，无需重启 MySQL。但要注意：
- 必须用有
GRANT OPTION权限的账号执行（如 root） - 如果主库用户是
'repl'@'192.168.1.%'，那@'192.168.1.%'也要同步改，host 不匹配照样连不上 - 改完立刻在从库执行
START SLAVE，别忘了先STOP SLAVE再RESET SLAVE ALL清旧配置
哪些情况不能靠参数或 ALTER USER 解决
当从库环境本身缺失 caching_sha2_password 插件支持时，比如：
- Docker 镜像用的是精简版 MySQL（如
mysql:8.0-slim），没打包该插件 - 从库是 MariaDB 或 Percona Server 旧版本，压根不识别该插件名
- 主库启用了强制 SSL（
require_secure_transport=ON），而你又不想配证书
这时就得上 SSL 方案：主库导出 ca.pem，从库 CHANGE MASTER TO ... MASTER_SSL=1 MASTER_SSL_CA='/path/to/ca.pem'。路径权限、证书有效期、CN 匹配这些细节，比改插件容易漏掉。
