CREATE USER 时必须显式指定 REPLICATION SLAVE 权限
MySQL 主从复制中，从库连接主库所用的账号不是普通用户，它需要能读取二进制日志（
binlog）并拉取事件。仅授予
SELECT或
REPLICATION CLIENT不够，必须明确赋予
REPLICATION SLAVE权限。
常见错误是沿用旧习惯建用户后补授权，但忘记刷新权限或漏掉该权限，导致从库报错：
ERROR 2003 (HY000): Can't connect to MySQL server on 'xxx' (1130)或更隐蔽的
ERROR 1236 (HY000): Got fatal error 1236 from master。 创建用户时直接授权比先建再授更可靠：
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'strong_pass_2024';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';<br>FLUSH PRIVILEGES;若使用 MySQL 8.0+，注意默认认证插件为
caching_sha2_password，某些旧版客户端不兼容，可显式指定：
CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'strong_pass_2024';主机名建议用具体 IP 或子网（如
'repl_user'@'192.168.1.%'），避免开放
'%'带来的安全风险
SHOW MASTER STATUS 输出的 File 和 Position 是 CHANGE MASTER TO 的关键参数
配置从库前，必须在主库执行
SHOW MASTER STATUS获取当前 binlog 文件名和位置点。这两个值会作为
CHANGE MASTER TO语句中的
MASTER_LOG_FILE和
MASTER_LOG_POS参数。
容易忽略的是：这个快照只代表「执行时刻」的状态，如果主库持续写入，从库启动延迟会导致跳过部分事件；若主库已切换 binlog（比如
FLUSH LOGS），而你仍用旧的
File名，就会报错
Could not find first log file name in binary log index file。 务必在主库低峰期或已停写时执行
SHOW MASTER STATUS记录输出中的
File（如
mysql-bin.000012）和
Position（如
154），不要手输，避免空格或大小写错误 从库执行
CHANGE MASTER TO后，必须运行
START SLAVE;才真正开始同步；仅
CHANGE MASTER TO不会自动启动
从库 my.cnf 中 server-id 必须唯一且不能为 1
MySQL 复制依赖
server-id区分节点身份。主库通常设为
1，所有从库必须设为其他非零整数（如
2、
101），且彼此不能重复。否则会出现
Slave I/O thread not running或日志循环写入问题。
另一个易错点是修改了
my.cnf却未重启 mysqld，或重启后未确认生效：
SELECT @@server_id;返回仍是旧值。 编辑
/etc/my.cnf或
/etc/mysql/mysql.conf.d/mysqld.cnf，在
[mysqld]段落下添加：
server-id = 2<br>log_bin = /var/lib/mysql/mysql-bin<br>read_only = ON
log_bin在从库上非必需，但开启有助于后续做级联复制；
read_only = ON可防误操作写入从库（注意：SUPER 用户仍可绕过） 重启后务必验证：
mysql -u root -p -e "SELECT @@server_id, @@log_bin;"
检查复制状态要用 SHOW SLAVE STATUS\G，别只看 Slave_IO_Running
SHOW SLAVE STATUS\G输出字段多，新手常只扫一眼
Slave_IO_Running和
Slave_SQL_Running都是
Yes就认为 OK。但实际同步异常往往藏在
Seconds_Behind_Master持续增长、
Until_Log_File非空、或
Retrieved_Gtid_Set与
Executed_Gtid_Set不一致里。
尤其当主库启用了 GTID（
gtid_mode = ON），从库必须用
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1，否则即使线程显示运行，也可能卡在事件解析阶段。 用
\G而非分号结尾，让字段垂直显示，便于定位关键项 重点关注：
Seconds_Behind_Master（应为
0或稳定小值）、
Relay_Master_Log_File（应与主库当前
File接近）、
Exec_Master_Log_Pos（是否持续前进） 若出现
SQL_Delay> 0，说明人为设置了延迟复制，此时
Seconds_Behind_Master显示的是延迟值而非真实滞后
配置复制不是一次性的操作，
server-id冲突、GTID 模式不匹配、binlog 位置漂移，任何一个细节出错都会让同步静默失败。最麻烦的是错误日志里没报错，但数据就是不同步——这时候得回到
SHOW SLAVE STATUS\G逐行比对字段含义。
