mysql 8.0主从复制报错“authentication requires secure connection”是因caching_sha2_password插件要求ssl连接，而从库io线程不支持；解决方法是在主库重建复制用户并指定mysql_native_password插件，再执行flush privileges，且从库需stop slave后重新change master to注册。
从库报错 Last_IO_Error: Authentication requires secure connection
这是 MySQL 8.0 主从连不上最典型的症状，根本不是密码错或网络不通，而是认证插件不兼容。MySQL 8.0 默认用 caching_sha2_password，而从库的 IO 线程（尤其是旧版 MySQL 客户端库、某些 Docker 镜像或未启用 RSA 公钥获取机制的环境）无法完成该插件要求的密钥交换流程。
验证方式很简单：SELECT user, host, plugin FROM mysql.user WHERE user = 'repl';，如果返回的 plugin 是 caching_sha2_password，且错误信息含 “secure connection”，基本就是它。
- 临时解决：在主库重建复制用户，显式指定旧插件：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pwd'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; - 长期方案：主库开启 RSA 密钥对并允许公钥传输（需配置
sha256_password_priv_key_path和sha256_password_pub_key_path），再配合从库客户端支持（如 PyMySQL ≥ 1.0.2 +ssl_disabled=False） - 注意：改完用户后，从库必须执行
STOP SLAVE; CHANGE MASTER TO ...重新注册，不能只重启 mysqld
从库连接主库时提示 ERROR 2061 或 Slave_IO_Running: No
这两个现象往往是一体两面：Slave_IO_Running: No 是结果，ERROR 2061 是日志里的具体报错码，指向“认证插件加载失败”或“插件不匹配”。它比上一条更底层——不是协议不支持，而是从库 mysqld 进程压根没加载 caching_sha2_password 插件，或者加载失败后 fallback 到了不兼容状态。
- 检查从库是否加载了对应插件：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.PLUGINS WHERE PLUGIN_NAME LIKE '%cache%'; - 若未启用，手动安装：
INSTALL PLUGIN caching_sha2_password SONAME 'caching_sha2_password.so';（路径可能因发行版而异，常见于/usr/lib/mysql/plugin/caching_sha2_password.so） - 但更常见的是容器镜像精简导致插件缺失——换用官方
mysql:8.0镜像，别用第三方魔改版 - 确认主库和从库的
default_authentication_plugin值一致（SELECT @@default_authentication_plugin;），不一致会引发隐式 fallback
容器环境下 nc -zv 能通，但从库还是连不上主库
网络层通 ≠ 数据库层通。Docker/K8s 中常见陷阱是：服务名解析正确、端口开放、防火墙放行，但主库 bind-address 配置仍为 127.0.0.1 或 ::1，导致只监听本地回环，拒绝容器网络来的连接。
- 查主库实际监听地址：
netstat -tlnp | grep :3306，确认输出含*:3306或0.0.0.0:3306，而非127.0.0.1:3306 - 强制修改
my.cnf：bind-address = 0.0.0.0（生产环境应配合skip-networking=OFF和最小化授权网段） - 容器内访问主库服务名时，注意 DNS 解析是否稳定——K8s headless service 或 docker-compose 的网络别名有时缓存过期，可加
host.docker.internal映射或直接用宿主机 IP 测试 - 从库
CHANGE MASTER TO中的MASTER_HOST必须填主库容器能解析到的地址，不能填 localhost 或 127.0.0.1
主库 show master status 正常，但从库 start slave 后立即挂掉
这通常不是连接问题，而是 GTID 模式下配置错位。MySQL 8.0 默认开启 GTID，一旦主库 gtid_mode=ON，从库就必须用 MASTER_AUTO_POSITION = 1，否则 START SLAVE 会静默失败或报错 Got fatal error 1236。
- 主库确认：
SELECT @@gtid_mode, @@enforce_gtid_consistency;，两者都应为ON - 从库执行
CHANGE MASTER TO时，严禁填写MASTER_LOG_FILE和MASTER_LOG_POS——GTID 模式下它们被忽略，还可能干扰自动定位 - 正确写法：
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION = 1; - 若之前手动设过位置，先清空：
RESET SLAVE;再重配，否则残留的 relay log 可能触发冲突
GTID 模式下 MASTER_AUTO_POSITION = 1 是开关，不是可选项；caching_sha2_password 的兼容性不是“要不要用”，而是“怎么让它在你的运行时里真正生效”。这两点漏掉任何一个，START SLAVE 都不会给你留情面。
