主库必须开启 binlog 且设置唯一 server-id
MySQL 主从复制依赖 binlog 记录写操作，如果主库没开 binlog，从库根本收不到任何事件。检查
my.cnf或
my.ini中是否包含：
log-bin = mysql-bin server-id = 1
注意：
server-id必须是正整数，主从不能相同；
log-bin路径默认在 datadir 下，不建议用绝对路径（易因权限或 SELinux 失败）；若已运行的实例首次启用 binlog，需重启 mysqld。
从库执行 CHANGE MASTER TO 时 host 和 port 要指向主库真实地址
常见错误是填了
127.0.0.1或
localhost，导致从库连自己而不是主库。务必确认网络可达，并用主库实际 IP 和开放端口（默认 3306）：
CHANGE MASTER TO MASTER_HOST = '192.168.1.10', MASTER_PORT = 3306, MASTER_USER = 'repl', MASTER_PASSWORD = 'xxx', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 154;
其中
MASTER_LOG_FILE和
MASTER_LOG_POS来自主库执行
SHOW MASTER STATUS的输出；用户
repl需提前在主库创建并授予
REPLICATION SLAVE权限。
START SLAVE 后立刻检查 Seconds_Behind_Master 是否为 NULL
Seconds_Behind_Master: NULL表示复制线程未正常启动，不是“追上了”，而是出错了。此时必须查：
SHOW SLAVE STATUS\G中的
Slave_IO_Running和
Slave_SQL_Running是否都为
Yes若
IO_Running为
No：大概率是网络不通、账号密码错、主库没开远程访问（
bind-address配置为
127.0.0.1）、防火墙拦截 若
SQL_Running为
No：常见于主从表结构不一致、从库有写入冲突、遇到重复键或缺失外键约束
错误日志在
SHOW SLAVE STATUS的
Last_IO_Error或
Last_SQL_Error字段里，别跳过这一步直接重试。
从库只读模式不能靠 set global read_only=1 一劳永逸
read_only=1对 super 用户无效，而 MySQL 系统账户（如
root@localhost）默认是 super，所以该设置形同虚设。真正防写入要组合两步： 执行
SET PERSIST read_only = ON（MySQL 8.0+）或写入配置文件并重启，确保持久生效 回收从库上所有非复制账号的
SUPER权限：
REVOKE SUPER ON *.* FROM 'app_user'@'%';
否则运维误操作或应用配置错账号，仍可能往从库写数据，后续主从数据就不可逆地不一致了。
