MySQL8.0 主从复制报错 2061：caching_sha2_password

在搭建 MySQL8.0.x（如 8.0.30）主从复制架构时，不少开发者会遇到从库启动失败的情况，查看从库状态会显示 Last_IO_Errno:2061 错误，具体提示为 “Authentication plugin 'caching_sha2_password' reported error: Authentication require secure connection”。这一问题的核心原因的是 MySQL 版本迭代带来的认证插件变更 ——MySQL8.0 之前默认使用 mysql_native_password 插件，而 8.0 及以上版本默认替换为更安全的 caching_sha2_password，主从复制时的身份验证机制不兼容导致连接失败。以下是三种经过实测的有效解决方法，可根据实际部署场景选择：

方法一：全局配置回归旧版认证插件

该方法适用于需要统一管理所有数据库用户认证方式的场景，通过修改 MySQL 服务端配置文件，让整个数据库实例默认使用 mysql_native_password 插件。

 

1. 找到 MySQL 的配置文件（Linux 系统通常为 /etc/my.cnf 或 /etc/mysql/my.cnf，Windows 系统为 my.ini）；
2. 在 [mysqld] 配置段中添加一行配置：default_authentication_plugin=mysql_native_password；
3. 重启 MySQL 服务（Linux：systemctl restart mysqld；Windows：服务面板中重启 MySQL 服务）；
4. 重新创建主从复制所需的 repl 用户，或重新授权已存在的 repl 用户，确保认证方式生效。

方法二：用户级别单独修改认证插件

若无需全局变更，仅需让主从复制的专用用户（如 repl）使用旧版认证插件，可直接通过 SQL 语句修改该用户的认证方式，不影响其他数据库用户。

 

执行以下 SQL 语句（需替换 [username]、[host] 和 [password] 为实际的用户名、访问主机（如 % 表示任意主机）和密码）：

 

alter user '[username]'@'[host]'
identified with mysql_native_password
by '[password]';

 

 

例如，针对主从复制用户 repl 配置允许任意主机访问：

 

alter user 'repl'@'%'
identified with mysql_native_password
by 'your_repl_password';

 

 

执行后无需重启 MySQL 服务，直接重启从库复制进程即可尝试连接。

方法三：连接时请求主库公钥（推荐优先尝试）

该方法无需修改主库配置或用户认证方式，通过在从库配置主从连接时添加公钥请求参数，适配 caching_sha2_password 插件的安全认证要求，是最灵活的解决方案。

 

在从库执行 change master to 命令时，额外添加 get_master_public_key=1 参数，完整命令示例如下（替换对应的主库地址、端口、用户名和密码）：

 

change master to 
master_host='你的主库IP', 
master_port=3308,  -- 主库MySQL端口
master_user='repl',  -- 主从复制专用用户
master_password='你的复制用户密码',
master_auto_position = 1,  -- 自动定位binlog位置（基于GTID）
get_master_public_key=1;  -- 关键参数：请求主库公钥完成安全认证

 

 

配置完成后，执行 start slave; 启动从库复制进程，再通过 show slave status\G 查看状态，若 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，则表示问题解决。