MySQL主从复制默认明文传输，必须显式启用TLS：主库需配置require_secure_transport=ON及SSL证书并重启，从库CHANGE REPLICATION SOURCE TO须完整指定SSL参数，复制账号须REQUIRE SSL且限定IP，同时从库应启用read_only与super_read_only双保险。
主从流量明文传输是默认行为，必须显式启用TLS
MySQL主从复制默认走纯文本协议，binlog、心跳包、甚至复制账户密码（若用基于账户的认证）都以明文形式在网络上传输。只要中间人能抓包（比如同网段、VPC未隔离、宿主机共享），就能直接看到SQL操作和凭据。光靠防火墙或内网假设不解决问题——require_secure_transport=ON必须在主库全局开启，否则从库即使配置了MASTER_SSL=1，主库仍会接受非加密连接。
- 主库my.cnf中必须加：
require_secure_transport=ON - 从库执行
CHANGE REPLICATION SOURCE TO时，SOURCE_SSL=1不能省略，且必须配SOURCE_SSL_CA（指向与主库一致的CA证书） - 验证是否生效：在从库运行
SHOW SLAVE STATUS\G，检查Source_ssl_allowed: Yes，且Seconds_Behind_Master正常；再用tcpdump抓包确认payload不可读
复制账户权限过大等于开放数据库只读接口
很多团队用root或admin账号做复制用户，这是高危操作。该账户一旦泄露，攻击者不仅能读取全量数据，还能执行START REPLICA、STOP REPLICA，甚至通过SHOW BINLOG EVENTS反推业务逻辑和敏感操作（如ALTER USER ... IDENTIFIED BY）。
- 单独创建最小权限账户：
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY '强密码' REQUIRE SSL; - 仅授予必要权限：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';，禁止GRANT OPTION - 从库上禁用
FILE、SHUTDOWN、PROCESS等非复制必需权限，防止提权或信息泄露
read_only=ON不是安全锁，super_read_only=ON才是
只设read_only=ON是常见“安全假象”。它阻止普通用户写入，但SUPER权限用户（包括复制线程本身）仍可执行INSERT、DROP TABLE等操作。一旦从库被入侵或误操作，双写导致主从不一致就不可逆。
- 从库my.cnf必须同时配置：
read_only=ON+super_read_only=ON（MySQL 5.7.20+才支持） - 确认生效：
SELECT @@read_only, @@super_read_only;两个值都应为1 - 注意：启用
super_read_only后，连SET GLOBAL这类操作也会被拒绝，需提前评估运维脚本兼容性
binlog加密不是开关一开就完事，密钥环配置失败会导致MySQL启动失败
binlog_encryption=ON看起来很美，但MySQL不内置密钥管理。它依赖keyring_file插件，而该插件对文件权限、存储位置极其敏感——稍有不慎，MySQL服务根本起不来，报错Plugin 'keyring_file' init function returned error。
- 必须在
[mysqld]节顶部加：early-plugin-load=keyring_file.so -
keyring_file_data=/var/lib/mysql-keyring/keyring路径需由mysql用户独占，权限严格为600，且不能位于NFS或容器临时卷 - 开启后，旧
binlog文件不会被加密，只对新生成的日志生效；SHOW VARIABLES LIKE 'binlog_encryption';返回ON才算成功
真正卡住落地的，往往不是概念，而是keyring_file_data目录权限不对、require_secure_transport漏配、或者以为read_only已足够防写入。这些点不逐个过一遍，所谓“安全复制”只是幻觉。
