主库必须开启 binlog 并设置唯一 server-id
MySQL 主从复制依赖 binlog，如果安装后没手动启用，
SHOW VARIABLES LIKE 'log_bin';会返回
OFF。必须在
my.cnf（Linux）或
my.ini（Windows）的
[mysqld]段落里显式配置：
log-bin = mysql-bin server-id = 1 binlog-format = ROW
server-id是整数，主库和从库不能相同；
binlog-format = ROW是推荐值，避免语句级复制在函数、时间戳等场景下产生不一致。
从库配置 server-id 并用 CHANGE MASTER TO 指向主库
从库同样要设唯一
server-id（比如
2），且不能重启前就执行复制命令。关键步骤是
CHANGE MASTER TO，它需要主库的 binlog 文件名和位置——这通常来自
SHOW MASTER STATUS;的输出。常见写法：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl', MASTER_PASSWORD='your_secure_password', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
注意：
MASTER_LOG_FILE和
MASTER_LOG_POS必须严格匹配主库当前状态，否则从库启动 IO 线程时会报错
Got fatal error 1236。
主库需创建专用复制账号并授权 REPLICATION SLAVE
不能用 root 或其他高权限账号做复制，安全起见应新建账号。在主库执行：
CREATE USER 'repl'@'%' IDENTIFIED BY 'your_secure_password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;
如果主库启用了
require_secure_transport=ON，从库连接时需加
MASTER_SSL=1参数，否则报错
Access denied for user 'repl'@'x.x.x.x' (using password: YES)，但错误信息不提示 SSL 问题，容易卡住。
START SLAVE 后检查 Seconds_Behind_Master 是否为 0
执行
START SLAVE;后，立刻用
SHOW SLAVE STATUS\G查看状态。重点关注三处：
Slave_IO_Running: Yes和
Slave_SQL_Running: Yes—— 两者都必须为
Yes
Seconds_Behind_Master: 0—— 表示已追平，非 0 说明有延迟
Last_IO_Error或
Last_SQL_Error—— 非空即出错，比如主键冲突、表不存在、SQL 线程被 stop 过
常见陷阱：从库开了
read_only=1但没关
super_read_only，会导致 SQL 线程无法写入，
Slave_SQL_Running显示
No且无明显错误日志。
