server_id必须全局唯一且不为0，否则Slave_IO_Running直接为No；log-bin必须启用、binlog-format推荐ROW；从库需显式配置relay-log和read-only=1，并通过SHOW MASTER STATUS与SHOW SLAVE STATUS\G实际验证。
主从复制环境能搭起来，但 server-id 冲突或 binlog 规则配错，会导致 SHOW SLAVE STATUS 里 Slave_IO_Running 直接为 No，连日志都拉不下来。
server-id 必须全局唯一，且不能为 0
MySQL 启动时会校验 server-id，如果为 0 或与其他节点重复，从库的 I/O 线程无法初始化连接主库。
-
server-id是整数，建议用 IP 最后一段（如192.168.31.52→server-id = 52），避免手误重复 - 主库和所有从库的
server-id必须互不相同；级联场景中，中间节点既是 slave 也是 master，server-id只设一个，但必须和上下游都不同 - 修改后必须重启 MySQL（
systemctl restart mysqld），仅 reload 配置不生效 - 验证方式：登录 MySQL 执行
SELECT @@server_id;，不是看配置文件
binlog 必须启用，且格式推荐 ROW
log-bin 是主从复制的物理前提，没它就根本没有可同步的日志；而 binlog-format 决定日志记录粒度，影响数据一致性。
-
log-bin值是路径前缀（如/usr/local/mysql/data/mysql-bin），不是完整文件名；目录需 MySQL 进程有写权限 - 务必设置
binlog-format = ROW：语句级（STATEMENT）在函数、时间函数、自增等场景下极易导致主从不一致 - 不要依赖
binlog-do-db做过滤 —— 它对跨库语句（如INSERT INTO db2.t SELECT * FROM db1.t）失效；真要过滤，用replicate-do-db放从库配置里更可靠 - 检查是否生效：
SHOW VARIABLES LIKE 'log_bin';返回ON，再执行SHOW BINARY LOGS;能列出文件才算真正启用
从库 relay-log 和 read-only 不是可选项
从库不配 relay-log 也能启动，但默认路径可能被 SELinux 或权限拦截；不设 read-only 则人为写入会直接破坏同步状态，且 SHOW SLAVE STATUS 中的 Seconds_Behind_Master 可能长期为 NULL。
-
relay-log建议显式指定路径（如mysql-relay-bin），避免和主库log-bin名称混淆 -
read-only = 1仅限制普通用户，super权限用户仍可写；如需彻底防护，加super_read_only = 1（MySQL 5.7+） - 从库若启用了
log-bin（例如要做级联），必须确保其server-id与上游主库不同，且自身也开启log-slave-updates = 1，否则中继日志不会写入自己的 binlog
最容易被忽略的是：所有配置改完后，必须分别在主库执行 SHOW MASTER STATUS;、在从库执行 SHOW SLAVE STATUS\G 对照验证，而不是只信配置文件内容。一次配错，CHANGE MASTER TO 的 MASTER_LOG_FILE 和 MASTER_LOG_POS 就全无效了。
