MySQL 主从复制默认不加密，必须手动启用 TLS
MySQL 主从复制在 5.7+ 默认使用明文传输 binlog 和心跳数据，包括用户名、密码（若用基于账户的复制）、甚至部分 DML 内容。只要网络可被中间人截获（如跨公网、VPC 边界、共享宿主机），凭据和数据就可能泄露。启用 TLS 是唯一能从根本上防止窃听和篡改的方式。
CHANGE REPLICATION SOURCE TO（8.0.22+）或
CHANGE MASTER TO（旧版）中必须显式指定
MASTER_SSL=1，否则即使服务端配置了证书，客户端（从库）仍会降级走非加密连接 主库需启用
require_secure_transport=ON（全局变量），否则仅靠从库设
MASTER_SSL=1不足以阻止主库接受未加密连接 证书验证不能只依赖
MASTER_SSL=1：必须配合
MASTER_SSL_CA（推荐），或至少设
MASTER_SSL_VERIFY_SERVER_CERT=1，否则无法防御 DNS 欺骗或 IP 劫持
正确配置主从 TLS 需要三类证书文件
不是“有证书就行”，而是主从双方角色对证书用途有严格区分。常见错误是复用同一套自签证书，导致握手失败或验证绕过。
主库需提供：ssl_cert（服务器证书）、
ssl_key（私钥）、
ssl_ca（CA 证书，用于验证从库传来的客户端证书，如果启用双向认证） 从库需提供：
MASTER_SSL_CA（用于验证主库身份）、
MASTER_SSL_CERT（可选，仅双向认证时需要）、
MASTER_SSL_KEY（同上） CA 证书必须相同：主库的
ssl_ca和从库的
MASTER_SSL_CA必须指向同一个 PEM 文件，否则
SSL error: certificate verify failed
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';
避免用 root 或高权限账号做复制用户
复制账号一旦泄露，攻击者可直接执行
START REPLICA、
STOP REPLICA，甚至通过
SHOW BINLOG EVENTS窥探敏感 SQL。最小权限原则在此尤为关键。 创建专用复制用户，仅授予
REPLICATION SLAVE权限，禁止
REPLICATION CLIENT（除非真需监控主库状态） 禁止复用应用账号或管理员账号；不要给复制用户
SELECT或
INSERT任意库的权限 若使用 MySQL 8.0+，启用
authentication_policy并强制密码复杂度，同时为复制用户设置
PASSWORD EXPIRE NEVER（避免自动过期中断复制）
CREATE USER 'repl'@'%' REQUIRE SSL; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;
加密之外的关键加固点：网络层与配置隔离
TLS 解决传输加密，但无法防御配置错误、日志泄露或本地提权。真实生产环境出问题，往往卡在这些环节。
主从之间禁用skip-networking，但必须绑定内网 IP（如
bind-address=10.0.1.10），严禁
0.0.0.0或注释掉该配置 从库的
my.cnf中
server-id必须唯一且非 1（主库通常为 1），否则可能导致 GTID 冲突或循环复制 关闭从库的
log_bin（除非要做级联复制），避免从库意外成为新主库后写入不可信 binlog
relay_log_info_repository=TABLE和
master_info_repository=TABLE必须开启，否则崩溃恢复时可能丢失复制位点，导致重复或跳过事务
复制链路的安全性不取决于某一个开关，而在于 TLS 配置、账号权限、网络暴露面、持久化机制四者的协同。最容易被忽略的是：从库的
MASTER_SSL_CA路径写错、或证书过期后没更新从库配置，此时复制看似正常运行，实则已退化为明文连接——连错误日志都不会报。
