主库必须启用binlog且server-id唯一；MySQL 5.7主从复制依赖binlog记录写操作，若log_bin未开启或server_id为0/重复，SHOW MASTER STATUS将返回空，从库无法获取同步起点。
主库必须启用 binlog 且 server-id 唯一
MySQL 5.7 主从复制依赖 binlog 记录所有写操作，如果 log_bin 未开启或 server_id 为 0 或重复，SHOW MASTER STATUS 会返回空，从库无法获取同步起点。
-
server_id必须是正整数（如1、2），两台机器不能相同；CentOS 7 下常见错误是配置文件里写了两次server_id，后一个覆盖前一个，导致实际值为 0 -
log_bin路径建议用绝对路径（如/var/lib/mysql/mysql-bin），避免 MySQL 启动时因权限或目录不存在而静默禁用 binlog - 执行
SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'server_id';确认值为ON和非零数字，不是靠重启就完事，要验证生效
从库 CHANGE MASTER TO 的参数必须严格匹配主库状态
从库执行 CHANGE MASTER TO 时，MASTER_LOG_FILE 和 MASTER_LOG_POS 必须与主库当前 SHOW MASTER STATUS 输出完全一致，否则启动复制会报错 Could not find first log file name in binary log index file 或卡在 Waiting for master to send event。
- 主库执行
SHOW MASTER STATUS;后立即记录File（如mysql-bin.000003）和Position（如154），中间不能有 DML 操作，否则 position 已变 - 从库命令中
MASTER_HOST填主库 IP（不是localhost），MASTER_USER和MASTER_PASSWORD必须与主库创建的复制账号一致（如'repl'@'%'） - 若主库已运行一段时间，推荐先锁表导出再同步：
FLUSH TABLES WITH READ LOCK;→mysqldump→UNLOCK TABLES;，否则从库可能因缺少历史数据而同步失败
START SLAVE 后必须检查 Seconds_Behind_Master 和 IO/SQL 线程状态
START SLAVE; 不等于复制就通了。真正要看 SHOW SLAVE STATUS\G 里的 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes，以及 Seconds_Behind_Master 是否稳定为 0 或小幅波动。
- 常见卡点：
Slave_IO_Running: No多半是网络不通（防火墙没关、3306未开放）、复制账号密码错、主库bind_address绑定127.0.0.1导致远程连不上 -
Slave_SQL_Running: No通常是数据冲突（如从库误写、主从表结构不一致）或跳过错误未配置，此时Last_SQL_Errno会显示具体错误码（如1062主键重复） - 不要只看
Seconds_Behind_Master是NULL就以为坏了——它为NULL表示 SQL 线程没在运行，优先查Slave_SQL_Running
验证同步必须在主库写、从库查，且避开系统库
测试不能只看 SHOW SLAVE STATUS 的状态，得用真实 DML 验证。但别往 mysql、information_schema 这些系统库写，它们默认被 binlog_ignore_db 忽略，不会同步。
- 建一个专用测试库：主库执行
CREATE DATABASE test_sync;→USE test_sync;→CREATE TABLE t1(id INT PRIMARY KEY, v VARCHAR(10)); - 主库插入：
INSERT INTO t1 VALUES (1, 'from_master');，等几秒后立刻去从库查：SELECT * FROM test_sync.t1; - 注意从库默认是只读的（
read_only=ON），如果手动改过从库数据，后续同步可能因主键冲突中断；生产环境务必保持从库read_only=1
主从配置里最容易被忽略的不是步骤顺序，而是每个环节的即时验证动作：改完配置必须 mysql -e "SHOW VARIABLES" 看真实值，CHANGE MASTER TO 后必须 SHOW SLAVE STATUS 查线程状态，写完数据必须立刻查从库——中间任何一步跳过，问题就会堆到验证阶段才暴露。
