必须只给REPLICATION SLAVE权限，因其专用于拉取binlog，授予SELECT、UPDATE等额外权限会导致越权风险；需精确限定host、执行FLUSH PRIVILEGES，并配合SSL加密与防火墙限制确保安全。
异地同步账号必须只给 REPLICATION SLAVE 权限
主从复制场景下，从库连接主库的账号不是普通应用账号，它只负责拉取 binlog 事件，不执行任何业务 SQL。给它 SELECT、UPDATE 甚至 ALL PRIVILEGES 都是严重越权——等于让灾备节点具备任意读写能力，一旦被攻破，RPO 归零且数据可篡改。
正确做法是仅授予 REPLICATION SLAVE，这是 MySQL 专为复制通道设计的最小权限集，包含读取 binlog 和请求 dump 的能力，其他一律禁止。
- 错误示例：
GRANT ALL PRIVILEGES ON *.* TO 'repl_user'@'203.205.128.45';—— 开放 DROP DATABASE、SHUTDOWN 等高危操作 - 正确命令：
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'203.205.128.45' IDENTIFIED BY 'strong_repl_pwd'; - 注意 host 必须精确匹配对端公网 IP 或 NAT 网关地址，不能用
'%'，否则可能被扫描利用
host 匹配错误会导致 SHOW GRANTS 看不到权限
执行完 GRANT REPLICATION SLAVE 后，用 SHOW GRANTS FOR 'repl_user'@'203.205.128.45'; 查不到结果？大概率是账号实际登录时匹配到了另一个 'repl_user'@'%' 或 'repl_user'@'localhost'，而你授的是另一个 host。
MySQL 认证时按 user@host 全匹配，'repl_user'@'203.205.128.45' ≠ 'repl_user'@'203.205.128.%'，也不等于 'repl_user'@'%'。必须确认从库连接串里写的 host 和授权时完全一致。
- 查真实匹配记录：
SELECT User, Host FROM mysql.user WHERE User = 'repl_user'; - 删掉冗余账号（如
'repl_user'@'%'）再重授，避免冲突 - 授完必须执行
FLUSH PRIVILEGES;，否则权限缓存在内存中未加载
跨地域链路需额外加固，权限只是起点
REPLICATION SLAVE 权限本身不加密、不校验身份，纯靠用户名密码明文传输——在公网直连时，密码可能被中间人截获。所以权限分配后，必须叠加网络层防护，否则“最少权限”形同虚设。
- 主库启用强制 SSL：
SET PERSIST require_secure_transport = ON;，并为repl_user绑定REQUIRE SSL - 从库连接时加参数：
CHANGE REPLICATION SOURCE TO ... SOURCE_SSL=1; - 禁用远程 root：
UPDATE mysql.user SET Host='localhost' WHERE User='root' AND Host!='localhost'; FLUSH PRIVILEGES;，防止灾备链路被当成跳板 - 若走公网，主库防火墙只放行从库 IP（如
203.205.128.45）的 3306 端口，别开整个段
权限验证不能只看 GRANT 语句是否成功
真正关键的是从库能否稳定运行 IO_THREAD，以及 SHOW REPLICA STATUS\G 中 Seconds_Behind_Master 是否持续增长或报错。权限不足时，常见现象不是直接拒绝连接，而是：
-
IO_Running: No，且Last_IO_Error显示Access denied; you need (at least one of) the SUPER or REPLICATION SLAVE privilege(s) - 主库
SHOW PROCESSLIST里看不到该账号的复制连接 - 从库 error log 出现
Could not find first log file name in binary log index file—— 实际是权限不够读取mysql-bin.index
最可靠的方式：用新账号在从库上手动执行一次 CHANGE REPLICATION SOURCE TO，观察是否报错；再启同步，盯 5 分钟 Seconds_Behind_Master 是否归零。权限这事，运行时行为比命令输出更诚实。
