为什么MySQL主从复制必须使用专用的Replication账号-mysql教程-PHP中文网

replication账号必须严格授予replication slave权限（gtid模式还需replication client），host须与从库真实出口ip完全一致，且必须执行flush privileges生效；权限缺失或host不匹配将导致io线程卡在“connecting to master”，无法拉取binlog。

为什么mysql主从复制必须使用专用的replication账号

Replication账号不是“能连上就行”，而是IO线程的唯一凭证

从库的IO线程连接主库时，不走普通客户端协议栈，它用的是MySQL内部复制协议（COM_BINLOG_DUMP），这个协议要求认证用户必须持有REPLICATION SLAVE权限。没有这个权限，哪怕密码正确、网络通、端口开，IO线程也会在“Connecting to master”状态卡死，日志里只显示ERROR 1236 (HY000): Could not open log file或Access denied; you need (at least one of) the SUPER or REPLICATION SLAVE privilege(s)。

给应用账号加REPLICATION SLAVE等于打开后门

很多同学图省事，直接把业务账号（比如app_user）加上REPLICATION SLAVE权限。这会导致两个严重问题：

一旦该账号泄露或被注入，攻击者可直接从主库拉取全量binlog，还原出所有写操作，包括敏感字段（如密码重置token、身份证号）
如果该账号还有UPDATE或DROP权限，攻击者可在从库执行STOP SLAVE; SET GLOBAL sql_slave_skip_counter=1; START SLAVE跳过校验，再往从库写脏数据，破坏主从一致性
DBA审计时无法区分“谁在同步”和“谁在查数”，权限边界彻底模糊

host匹配错误比权限漏授更常见

权限没给对还能报错，但host写错会静默失败——IO线程连得上，却始终不拉日志。关键点：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

CREATE USER 'repl'@'192.168.5.20'和GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.5.20'必须完全一致，'repl'@'%'和'repl'@'192.168.5.%'是不同账号
MySQL 8.0+默认用caching_sha2_password插件，'repl'@'%'无法远程认证，必须显式指定从库真实出口IP
如果从库在Docker里跑，宿主机ifconfig看到的IP不是容器内网IP，而是Docker网桥地址（如172.17.0.2），host得填这个

GTID模式下REPLICATION CLIENT不是可选，是刚需

启用GTID后，从库启动时会自动执行SELECT @@global.gtid_executed来比对事务集合，这个语句需要REPLICATION CLIENT权限。只给REPLICATION SLAVE会导致START SLAVE直接报错：ERROR 1227 (42000): Access denied。实操中建议统一授予：

CREATE USER 'repl'@'192.168.5.20' IDENTIFIED BY 'strong_pass_2024';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.5.20';
FLUSH PRIVILEGES;

真正容易被忽略的不是“要不要给”，而是FLUSH PRIVILEGES这一步——权限表缓存在内存，不刷就不会生效，哪怕你刚GRANT完也白搭。