主库必须配置非零唯一server-id并开启log-bin，且binlog_format须显式设为ROW；从库需设唯一server-id但通常不启用log-bin，否则复制无法启动。
主库不设 server-id 或没开 log-bin，从库 START SLAVE 后 IO_Running 必为 No，不是网络或权限问题，是根本没日志可拉。
主库必须配 server-id 且开启 log-bin
这是主从复制的硬性前提，缺一不可。很多 Docker 镜像、一键脚本默认关掉 log-bin，或者压根没写 server-id，导致后续所有操作都白忙。
-
server-id必须是非零正整数（如1），且在同局域网内全局唯一；主库设1是惯例，但不是强制，关键是不能和任何从库重复 -
log-bin推荐写绝对路径，比如log-bin = /var/lib/mysql/mysql-bin，避免 MySQL 启动时因工作目录不确定而创建失败 - 改完配置必须重启 MySQL：
systemctl restart mysql，mysqladmin reload或SET GLOBAL类命令无效 - 验证是否生效：进 MySQL 执行
SHOW VARIABLES LIKE 'log_bin';（应返回ON）和SHOW VARIABLES LIKE 'server_id';（应返回你设的数字）
binlog_format 必须设为 ROW，不能依赖默认值
MySQL 5.7+ 虽默认 ROW，但旧版本、某些 Docker 镜像或定制包仍可能用 MIXED 或 STATEMENT。后者在含 NOW()、UUID()、自增列、触发器等语句时，极易导致主从数据不一致甚至 SQL_Running: No。
- 在主库
my.cnf的[mysqld]段显式写死：binlog_format = ROW - 该参数不可动态修改：
SET GLOBAL binlog_format = 'ROW'在运行时会报错 - 如果已用
STATEMENT同步了一段时间，切到ROW前建议停写、清空 relay log、重做全量同步，否则切换点附近容易出错
从库也要配 server-id，但普通场景下别开 log-bin
从库没设 server-id，CHANGE MASTER TO 可能成功，但 START SLAVE 后立刻失败，错误常是 Client requested master to start replication from impossible position——本质是 MySQL 拒绝给无 ID 的实例建立复制连接。
- 从库
server-id必须与主库及其他从库不同，例如主库是1，从库可设2、101等 - 普通从库**不要**配
log-bin；开了又不用于级联，只会多占磁盘、拖慢性能，还可能干扰日志轮转和状态判断 - 只有要做“中间主库”（即这台从库还要再同步给下一级从库）时，才需同时设
server-id和log-bin
常见错误现象与快速定位方法
当 SHOW SLAVE STATUS\G 显示 IO_Running: No 或 SQL_Running: No，别急着查网络或权限，先看最基础的三项：
- 主库执行
SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'server_id';——两个都必须有有效值 - 从库执行
SHOW VARIABLES LIKE 'server_id';——不能为0，也不能和主库或其他从库重复 - 主库错误日志（通常是
/var/log/mysql/error.log）里搜Could not find first log file name in binary log index file——基本就是log-bin没生效或路径不对
这些配置项一旦写错，后续所有复制动作都是空中楼阁；最容易被忽略的是 log-bin 路径写相对路径、binlog_format 没强制指定、以及从库误开 log-bin 却不用于级联。
