最安全的从库同步账号配置是使用replication slave权限、限定具体ip（如'repl'@'192.168.10.5'）和强密码，不赋select等额外权限，配合防火墙最小化放行及tls加密。
复制账号必须绑定具体IP或子网，不能用'%'通配符
生产环境里，repl这类复制账号如果授权时用了'repl'@'%'，等于把主库binlog读取权限开放给任意IP，攻击者一旦爆破或窃取密码，就能拉取全量日志甚至构造恶意SQL回放。MySQL本身不校验连接来源是否“合理”，只认账号+密码+主机名三元组。
实操建议：
- 主库创建账号时直接限定从库IP：
CREATE USER 'repl'@'192.168.10.5' IDENTIFIED BY 'StrongPass123!'; - 若有多台从库，用CIDR子网更可控：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.10.%';（注意是192.168.10.%，不是192.168.10.0/24） - 禁止在测试环境养成
'repl'@'%'习惯——上线前漏改，等于留后门 - 执行
FLUSH PRIVILEGES;后，立刻用SELECT User, Host FROM mysql.user WHERE User = 'repl';确认Host字段值
防火墙要同步限制3306端口的访问源
仅靠MySQL账号Host限制不够。如果攻击者能绕过MySQL认证（比如利用本地提权、UDF漏洞），或者主库监听在0.0.0.0且防火墙没设规则，'repl'@'192.168.10.5'照样可能被其他IP冒用——只要网络层能连上3306端口。
实操建议：
- Linux用
iptables或ufw只放行从库IP：ufw allow from 192.168.10.5 to any port 3306 - 云厂商安全组规则必须精确到从库ECS实例内网IP，禁用“全部内网”或“0.0.0.0/0”
- 验证：从非授权IP执行
telnet master_ip 3306应直接超时或拒绝连接，而非进入MySQL握手流程 - 若主库启用了
require_secure_transport=ON，还需确保从库连接时带MASTER_SSL=1参数，否则START SLAVE会报ERROR 2003
复制账号密码轮换后，从库CHANGE MASTER TO必须同步更新
账号密码改了，但从库CHANGE MASTER TO语句里还用旧密码，会导致Slave_IO_Running: No且Seconds_Behind_Master: NULL。错误日志里通常只写Access denied for user 'repl'@'xxx'，容易误判为网络或权限问题。
实操建议：
- 密码变更后，在从库执行：
CHANGE MASTER TO MASTER_PASSWORD='NewPass123!';（MySQL 5.7+） - MySQL 8.0.23+推荐用
CHANGE REPLICATION SOURCE TO SOURCE_PASSWORD='NewPass123!'; - 不要用
SET PASSWORD FOR 'repl'@'xxx' = 'xxx';代替——这只会改密码，不会通知从库重连 - 更新后运行
START SLAVE;并立刻检查SHOW SLAVE STATUS\G中Slave_IO_Running和Seconds_Behind_Master状态
read_only + super_read_only不能替代Host限制
有人以为开了read_only=ON或super_read_only=ON就万事大吉，其实这些参数只防“写”，不防“连”。复制账号仍能连上主库、读取binlog、甚至通过SELECT INTO OUTFILE导出敏感数据——只要它有REPLICATION SLAVE权限。
关键点：
-
read_only对SUPER权限用户无效；super_read_only才真正锁死所有写操作，但依然不限制连接来源 - Host限制是网络层第一道关卡，
read_only是数据库层最后一道防线，二者缺一不可 - 检查从库是否意外获得SUPER权限：
SELECT User, Host, Super_priv FROM mysql.user WHERE User = 'repl';结果必须是N
真正起作用的是Host字段值和防火墙规则的组合，而不是某一个配置项。哪怕super_read_only=ON开着，只要'repl'@'%'存在且防火墙放行，风险就始终在线。
