公网mysql主从复制必须启用tls加密，否则所有数据明文传输；主库需配置ssl证书、require_secure_transport=on并重启，从库change replication source to须显式指定全部ssl参数且复制账号必须require ssl并限定ip。
公网环境下 MySQL 主从复制必须启用 TLS 加密，否则 binlog 流、用户名、密码、甚至部分 SQL 内容全以明文传输，抓包即可还原全部写操作——这不是“可能被窃听”，而是“必然裸奔”。
主库必须同时满足 SSL 启用 + 强制加密连接
只配证书不设强制策略，等于没锁门。主库启动后需确认三件事：
-
SHOW VARIABLES LIKE 'have_ssl'返回YES（不是DISABLED或空） -
ssl_ca、ssl_cert、ssl_key均指向真实可读的绝对路径，且私钥权限为600 -
require_secure_transport = ON已写入[mysqld]段并重启生效——漏掉这句，从库即使配了 SSL 也会被主库降级接受明文连接
常见错误：改完配置没重启 mysqld，或把 SSL 参数错放在 [client] 段；SET GLOBAL require_secure_transport = ON 无效，必须写进配置文件。
从库 CHANGE REPLICATION SOURCE TO 必须显式带全 SSL 参数
MASTER_SSL = 1 单独出现毫无意义。MySQL 复制客户端会静默回退到明文，且不报错——你得靠 SHOW SLAVE STATUS\G 里 Slave_SSL_Allowed: Yes 和 Master_SSL_Cipher 非空来确认真正在用加密。
- 必须成对提供：
SOURCE_SSL_CA（验证主库身份）、SOURCE_SSL_CERT与SOURCE_SSL_KEY（仅双向认证需要） -
SOURCE_SSL_CA必须和主库的ssl_ca是同一份 PEM 文件，否则握手失败报SSL error: certificate verify failed - 示例命令（MySQL 8.0.22+）：
CHANGE REPLICATION SOURCE TO SOURCE_HOST = 'master.example.com', SOURCE_USER = 'repl', SOURCE_PASSWORD = 'xxx', SOURCE_SSL = 1, SOURCE_SSL_CA = '/etc/mysql/ca.pem', SOURCE_SSL_CERT = '/etc/mysql/client-cert.pem', SOURCE_SSL_KEY = '/etc/mysql/client-key.pem', SOURCE_LOG_FILE = 'mysql-bin.000001', SOURCE_LOG_POS = 154;
复制账号必须 REQUIRE SSL 且限制 IP
哪怕 TLS 已启用，如果复制用户没强制 SSL，攻击者仍可用该账号发起明文连接，绕过所有加密防护。
- 创建时必须加
REQUIRE SSL：CREATE USER 'repl'@'192.168.10.5' IDENTIFIED BY 'StrongPass123!' REQUIRE SSL;
- 禁止用
%通配符，明确指定从库 IP；配合系统防火墙或云安全组，只放行该 IP 的3306端口 - 权限仅限
REPLICATION SLAVE，禁止REPLICATION CLIENT、SELECT或任意库写权限
别复用应用账号——复制账号一旦泄露，攻击者可直接执行 START REPLICA、SHOW BINLOG EVENTS，拿到所有变更细节。
公网部署还要防证书链失效和时间漂移
自签名证书在公网场景下风险极高：没有可信 CA 背书，SOURCE_SSL_VERIFY_SERVER_CERT = 1 实际形同虚设；而生产环境若用公共 CA，证书有效期、域名匹配、OCSP 响应延迟都可能让复制中断。
- 务必检查证书有效期：
openssl x509 -in ca.pem -noout -dates - 主从系统时间差超过 5 分钟，TLS 握手大概率失败（X.509 时间戳校验），
ntpd或chrony必须同步 - 不要复用应用连接的证书；主从复制通道建议用专用 CA 签发，避免私钥泄露波及业务
最易忽略的一点：MySQL 错误日志里那些看似无关的 SSL library error 或 Failed to set up SSL 提示，往往比客户端报错更早暴露证书路径错、权限不对、OpenSSL 版本不兼容等问题——别只盯着 SHOW SLAVE STATUS 看。
