最安全的从库同步账号配置是使用 REPLICATION SLAVE 权限、限定具体 IP（如 'repl'@'192.168.10.22'）和强密码，不赋 SELECT 等额外权限，配合防火墙最小化放行及 TLS 加密。
直接给结论：用 REPLICATION SLAVE 权限 + 明确 IP 限制 + 强密码，不赋任何其他权限，这是从库同步账号最安全的配置方式。别用 %，也别顺手加 SELECT 或 ALL PRIVILEGES —— 那不是“方便”，是留后门。
为什么必须限制账号访问 IP 而不是用 '%'？
复制账号只服务于特定从库，'repl'@'%' 意味着任意 IP 都能连主库并读取 binlog，而 binlog 里可能包含敏感字段（如密码哈希、脱敏前手机号等）。一旦该账号泄露或被横向移动，攻击者可直接拉取全量变更日志。
- 生产环境务必写成
'repl'@'192.168.10.22'（从库真实内网 IP）或'repl'@'10.0.5.0/24'（最小必要网段） - 若从库走跳板机或 NAT 出口，需确认实际连接源 IP，可用
tcpdump -i any port 3306 -A在主库抓包验证 - MySQL 8.0+ 支持主机名解析，但 DNS 不稳定时会导致连接失败，优先用 IP
GRANT REPLICATION SLAVE 的权限范围是否足够？
够，而且只能给这个。该权限仅允许账号执行 SHOW BINLOG EVENTS 和作为从库连接时读取 binlog 流，不涉及任何表级操作。加其他权限反而增加风险：
-
SELECT：让账号能直接查主库任意数据，绕过应用层鉴权 -
REPLICATION CLIENT：虽常被误加，但它只是用于监控（如SHOW MASTER STATUS），从库启动复制不需要它 -
SUPER或PROCESS：完全没必要，且可能被用于提权或绕过read_only
验证命令：SHOW GRANTS FOR 'repl'@'192.168.10.22'; 输出应只有且仅有这一行：GRANT REPLICATION SLAVE ON *.* TO `repl`@`192.168.10.22`
密码策略和账号生命周期怎么管？
复制账号长期有效但必须可控。常见疏漏是密码硬编码在 CHANGE MASTER TO 语句里，或存于未加密的运维脚本中：
- 密码长度不低于 12 位，含大小写字母+数字+符号，避免使用字典词或日期
- 不要把密码写进
CHANGE MASTER TO的明文语句；MySQL 8.0+ 推荐用MASTER_USER='repl', MASTER_PASSWORD='' , GET_MASTER_PUBLIC_KEY=1+ SSL 连接，密码由 MySQL 内部密钥交换机制传递 - 定期轮换（如每 90 天），轮换时先在主库改密码：
ALTER USER 'repl'@'192.168.10.22' IDENTIFIED BY 'new_strong_pass';，再在从库执行STOP SLAVE; CHANGE MASTER TO MASTER_PASSWORD='new_strong_pass'; START SLAVE; - 禁用长期闲置账号：
DROP USER 'repl'@'192.168.10.22';，别只删权限
防火墙和网络层还要做哪些配合？
账号权限再严，挡不住网络层放行。主库的 3306 端口必须按最小原则开放：
- iptables / firewalld 规则只允许可信子网的源 IP 访问：
-A INPUT -s 192.168.10.22/32 -p tcp --dport 3306 -j ACCEPT - 云厂商安全组同理，拒绝所有默认入向，仅放通从库 IP
- 若主从跨公网，强制启用 TLS：
MASTER_SSL=1, MASTER_SSL_CA='/path/to/ca.pem', MASTER_SSL_CERT='/path/to/client-cert.pem', MASTER_SSL_KEY='/path/to/client-key.pem' - 注意：MySQL 默认不校验证书 CN，需额外加
MASTER_SSL_VERIFY_SERVER_CERT=1才真正防中间人
真正容易被忽略的是 server-id 冲突和 UUID 重复 —— 它们不会导致账号不安全，但会让复制静默失败。每次克隆 MySQL 实例后，必须删掉从库 data/auto.cnf 并重启，否则 SHOW SLAVE STATUS 里会卡在 Slave_IO_Running: No，错误码 1593。
