mysql主从复制需主库开启binlog并设唯一server-id；从库change master to须指向主库真实ip和端口；start slave后seconds_behind_master为null表明复制未启动，需检查io/sql线程状态及错误日志；从库只读须set persist read_only=on并回收super权限。
主库必须开启 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'@'%';
否则运维误操作或应用配置错账号，仍可能往从库写数据，后续主从数据就不可逆地不一致了。
