MySQL 8.0+创建复制账号必须显式指定mysql_native_password插件，因默认caching_sha2_password会导致“Authentication plugin cannot be loaded”认证失败；需用CREATE USER 'repl'@'真实IP' IDENTIFIED WITH mysql_native_password BY '密码'并GRANT REPLICATION SLAVE ON .，再FLUSH PRIVILEGES。
MySQL 8.0+ 创建复制账号必须显式指定 mysql_native_password 插件
从库连接主库时若用默认的 caching_sha2_password 插件，会直接报错：Authentication plugin 'caching_sha2_password' cannot be loaded。这不是权限或网络问题，是认证机制不兼容。
必须在 CREATE USER 中用 IDENTIFIED WITH 显式声明插件：
CREATE USER 'repl'@'10.0.2.15' IDENTIFIED WITH mysql_native_password BY 'StrongPass!2026';
- 不能省略
IDENTIFIED WITH—— 即使密码正确，没写这句就沿用默认插件，从库连不上 -
mysql_native_password是目前最稳妥的选择；caching_sha2_password在主从链路中支持不稳定，尤其跨版本时 - MySQL 9.6.0（2026年发布）已原生支持
caching_sha2_password主从握手，但当前生产环境仍以 8.0.x 为主，不建议冒险
GRANT REPLICATION SLAVE ON *.* 的作用域不可缩窄
复制账号权限必须全局授予，ON *.* 是硬性要求。试图限定到某个库（如 ON `mydb`.*）会导致从库启动失败，错误提示类似：You need the SUPER or REPLICATION SLAVE privilege(s)。
正确授权语句只有一行，且不能加其他权限：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.2.15';
- 不要给
SELECT、ALL PRIVILEGES等额外权限——复制账号只做 binlog 传输，业务权限无意义，反而增加审计风险 - 生产环境禁止用
'repl'@'%'，必须写死从库真实 IP（如'repl'@'10.0.2.15'），这是最小权限原则落地的关键一步 - 执行完必须跟
FLUSH PRIVILEGES;，否则权限不生效，从库连接时仍报Access denied
密码明文落盘风险与替代方案
CHANGE MASTER TO 中的 MASTER_PASSWORD 会以明文写入 mysql.slave_master_info 表（或磁盘文件），这是 MySQL 内部机制决定的，无法绕过。
这意味着：只要有人能查从库系统表或拿到备份文件，就能看到主库复制账号密码。
- 密码强度必须高，且**绝不能复用其他业务账号密码**
- 若合规要求严格（如等保三级），可改用
START SLAVE USER='repl' PASSWORD='StrongPass!2026';方式——该命令不落盘密码，但要求主从均为 MySQL 8.0.22+，且master_info_repository=TABLE（默认已启用） - 注意：
START SLAVE USER是运行时临时凭证，MySQL 重启后需重新执行；它不能替代CHANGE MASTER TO的持久化配置
检查账号是否真的可用
创建完账号别急着切从库，先在主库本地模拟从库连接行为，验证账号是否真能连通：
mysql -h 127.0.0.1 -u repl -p -P 3306
如果连不上，优先排查以下三点：
- 主库
bind-address是否设为0.0.0.0或具体监听 IP（不是默认的127.0.0.1） - Linux 防火墙是否放行 3306 端口：
firewall-cmd --list-ports | grep 3306 - SELinux 是否拦截：
ausearch -m avc -ts recent | grep mysqld，若存在拒绝日志，临时关闭测试：setenforce 0
真正麻烦的从来不是语法写错，而是网络层和安全策略挡在了第一步。账号配得再准，连不上等于白搭。
