MySQL 8.0 SSL主从复制必须显式配置全部SSL参数，仅设SOURCE_SSL=1无效；必须同时指定SOURCE_SSL_CA、SOURCE_SSL_CERT、SOURCE_SSL_KEY（路径为从库本地且mysql用户可读），否则静默退化为明文连接或认证失败。
MySQL 8.0 主从复制走 SSL，光配服务端证书没用，CHANGE REPLICATION SOURCE TO 必须显式传全 SSL 参数，漏一个就退化成明文，且不报错。
为什么 CHANGE REPLICATION SOURCE TO 加了 SOURCE_SSL=1 还连不上主库
常见错误是只写 SOURCE_SSL=1，以为这就启用了 SSL。实际不是——MySQL 会尝试 SSL 握手，但若缺少 SOURCE_SSL_CA，它会静默失败并回退到明文连接；而 SHOW REPLICA STATUS\G 里只显示 Master_SSL_Allowed: No，不会中断重试，IO 线程持续报 Access denied 或 Authentication requires secure connection。
-
SOURCE_SSL_CA是强制项，必须指定，路径为从库本地可读的 PEM 文件（如/etc/mysql/ssl/ca.pem） -
SOURCE_SSL_CERT和SOURCE_SSL_KEY不是可选的“增强项”，而是双向认证必需（尤其当主库用户设了REQUIRE X509或REQUIRE SUBJECT） -
SOURCE_SSL_CIPHER一般不用设，除非主库明确限制了加密套件（如ssl_cipher = 'TLS_AES_256_GCM_SHA384'） - 所有路径必须由
mysql用户可读，SELinux/AppArmor 拦截时会静默失败，查ausearch -m avc -ts recent确认
CHANGE REPLICATION SOURCE TO 的 SSL 参数必须怎么写
完整、最小可用的 SSL 复制连接语句长这样（注意路径是从库本地，不是主库路径）：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.10.27', SOURCE_USER='repl', SOURCE_PASSWORD='YourPassword123!', SOURCE_PORT=3306, SOURCE_SSL=1, SOURCE_SSL_CA='/etc/mysql/ssl/ca.pem', SOURCE_SSL_CERT='/etc/mysql/ssl/client-cert.pem', SOURCE_SSL_KEY='/etc/mysql/ssl/client-key.pem';
关键点：
-
SOURCE_SSL=1必须显式写，不能省略或写成ON/TRUE（MySQL 只认整数 1） -
SOURCE_SSL_CA必须和主库的ssl_ca文件内容完全一致，哪怕多一个空格都会握手失败，错误信息是SSL error: certificate verify failed - 从库的
client-cert.pem和client-key.pem必须由同一 CA（即ca.pem）签发，且私钥不能加密（openssl rsa -in client-key.pem -noout不提示输入密码才算合格） - 如果主库用户是用
CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx' REQUIRE SSL;创建的，那从库只需SOURCE_SSL_CA就够；但如果用了REQUIRE X509，就必须带CERT和KEY
主库 require_secure_transport=ON 后，从库不配 SSL 就根本连不上
这是最容易被忽略的硬性前提：主库开了 require_secure_transport=ON（推荐用 SET PERSIST 设置），意味着它拒绝一切非 SSL 连接。此时从库即使只漏掉 SOURCE_SSL_CA，也会在 TCP 层建立后立即被主库断开，日志里出现：
2026-05-09T22:15:03.882142Z 127 [Warning] [MY-013360] [Server] Access denied for user 'repl'@'192.168.10.28' (using password: YES) (Client does not support authentication protocol requested by server; consider upgrading MySQL client)
或者更直接的：
ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection
这说明不是账号密码问题，而是连接根本没走到认证阶段——SSL 握手已失败。
- 验证主库是否真生效：
SELECT @@require_secure_transport;返回1 - 检查主库是否加载了证书：
SHOW VARIABLES LIKE 'ssl%';中ssl_cipher非空，且have_ssl = YES - 从库执行
START REPLICA;后立刻查SHOW REPLICA STATUS\G，重点看Master_SSL_Allowed和Seconds_Behind_Master；若前者是No，基本可断定 SSL 参数不全或路径失效
证书路径和权限问题比语法错误更常导致失败
很多配置看起来完全正确，但就是连不上，最终发现是路径或权限卡住：
- 路径必须是绝对路径，
./ssl/ca.pem或相对路径无效 - 文件属主必须是
mysql:mysql，权限建议640（ca.pem可放宽到644，但client-key.pem绝对不能是644） - 目录本身也要有执行权限（
chmod 750），否则 MySQL 进程进不去 - Ubuntu/Debian 默认用
apparmor，CentOS/RHEL 默认用selinux，它们会拦截对非标准路径（如/root/ssl/）的读取，错误不报在 MySQL 日志里，而在系统日志中 - MySQL 8.0.43+ 可用
mysql_ssl_rsa_setup --datadir=/var/lib/mysql --uid=mysql重生成一套标准证书，避免手动生成时格式出错
真正麻烦的从来不是“怎么写”，而是“为什么写了却不生效”——SSL 复制失败时，90% 的时间花在确认证书路径、权限、CA 一致性上，而不是语法纠错。
