从库同步账号必须在主库创建并授权，因为从库I/O线程需主动连接主库拉取binlog，依赖CHANGE REPLICATION SOURCE TO中指定的SOURCE_USER和SOURCE_PASSWORD进行身份验证；该用户须在主库被授予REPLICATION SLAVE（及GTID模式下还需REPLICATION CLIENT）权限，且主机段应精确限定网段而非使用'%'，密码不可加引号，用户名区分大小写，不可复用业务账号以遵循最小权限原则。
从库同步账号为什么必须在主库上创建并授权
因为从库的 IO 线程是「主动连接主库」拉取 binlog 的，它用的是 CHANGE REPLICATION SOURCE TO 里填的 SOURCE_USER 和 SOURCE_PASSWORD，这个用户必须能在主库上完成身份验证并执行 binlog 读取操作。权限不是配在从库，也不是配给应用账号——配错位置，IO_Running: No 就必然出现。
-
REPLICATION SLAVE权限必须授予在主库，且只对*.*生效（不能限定库或表） - 从库 IP 必须能连通主库的 3306 端口，且主库
bind-address不能是127.0.0.1（否则拒绝远程连接） - MySQL 8.0+ 默认使用
caching_sha2_password插件，若从库客户端不支持，需显式指定IDENTIFIED WITH mysql_native_password BY
GRANT REPLICATION SLAVE 时最容易漏掉的两个条件
很多团队执行完 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' 就以为完事了，结果从库始终连不上。其实有两个隐性但关键的约束：
- 用户主机段不能写成
'%'—— 它允许任意 IP 连接，包括公网，存在暴露风险；应精确到从库网段，比如'192.168.10.50'或'192.168.10.%' - 如果主库启用了 GTID（
gtid_mode = ON），仅REPLICATION SLAVE不够：从库启动时会尝试执行SHOW MASTER STATUS获取初始位点，这需要REPLICATION CLIENT权限，否则报错Access denied; you need ... REPLICATION CLIENT privilege
正确做法是这两条都执行：
CREATE USER 'repl_user'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'aB3#xY9!qL2$'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.10.%'; GRANT REPLICATION CLIENT ON *.* TO 'repl_user'@'192.168.10.%';
从库配置 CHANGE REPLICATION SOURCE TO 时的三个硬性校验点
即使主库权限全给了，从库这一步写错一个字符也会导致同步失败。重点盯住以下三项：
-
SOURCE_USER值必须和主库上CREATE USER的用户名**完全一致**，包括大小写（MySQL 8.0+ 用户名区分大小写） -
SOURCE_PASSWORD后面的值**不能加单引号或双引号**，否则会被当字面量解析，密码传过去就错了 -
SOURCE_HOST必须是主库可被从库 ping 通的地址，不能是localhost或127.0.0.1（除非主从在同一台机器且用 socket 连接，但极少见）
典型正确写法：
CHANGE REPLICATION SOURCE TO SOURCE_HOST = '192.168.10.100', SOURCE_USER = 'repl_user', SOURCE_PASSWORD = 'aB3#xY9!qL2$', SOURCE_PORT = 3306;
为什么不能复用业务账号做同步用户
用 root、admin 或某个业务 SELECT 账号直接当同步用户，短期能跑通，但埋下严重隐患：
- 该账号一旦泄露，攻击者不仅能读 binlog（含所有 DML 内容），还能执行任意 SQL（如果它有 SUPER 或其他高危权限）
- 权限审计时无法区分「谁在查数据」和「谁在拉日志」，违反最小权限原则
- 某些中间件（如 ProxySQL、ShardingSphere）会基于账号名做路由策略，混用会导致误判
同步账号的本质是「网络服务凭证」，不是「人用账号」。它只干一件事：让从库的 IO 线程能稳定、安全地拿到 binlog 流。其余权限一概不要，连 SELECT 都不该有。
