主库需开启binlog并设唯一server-id：配置server-id=1、log-bin=/var/lib/mysql/mysql-bin、binlog-format=ROW、expire_logs_days=7；从库通过CHANGE REPLICATION SOURCE TO独立连接主库，依赖各自relay_log和master.info互不干扰；延迟判断应比对File/Position或GTID集合，而非仅看Seconds_Behind_Master。
主库怎么配：开启 binlog 并设唯一 server-id
主库必须启用二进制日志，否则从库根本没东西可同步。binlog_format 推荐用 ROW，避免语句级复制在函数、临时表等场景下出错。同时确保 server-id 是非零整数，且全局唯一——多个从库可以共用同一个 server-id 吗？不行，主库和每个从库都必须不同，否则 GTID 或传统复制会拒绝连接。
关键配置项（my.cnf）：
server-id = 1 log-bin = mysql-bin binlog-format = ROW expire_logs_days = 7
-
log-bin路径不能是相对路径，建议写绝对路径（如/var/lib/mysql/mysql-bin），否则重启后可能失效 - 如果主库已运行，改完配置要重启 MySQL；但
binlog_format可在线改（SET GLOBAL binlog_format = 'ROW'），不过只对新会话生效，稳妥起见还是重启 - 别漏掉
expire_logs_days，不然 binlog 无限增长，磁盘迟早爆
从库怎么连：CHANGE REPLICATION SOURCE TO 指向同一主库
每个从库独立执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+ 语法，旧版用 CHANGE MASTER TO），目标都是同一个主库的 IP 和端口，但各自用不同的复制用户账号（或同一账号也行，只要权限够）。重点不是“能不能连”，而是“连上之后怎么不互相干扰”——靠的是每个从库维护自己的 relay_log 文件和 master.info（或 performance_schema 表），互不影响。
- 主库上必须创建有
REPLICATION SLAVE权限的用户，比如：CREATE USER 'repl'@'%' IDENTIFIED BY 'pwd'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; - 从库执行
CHANGE REPLICATION SOURCE TO时，SOURCE_LOG_FILE和SOURCE_LOG_POS必须和主库当前SHOW MASTER STATUS一致；用mysqldump --single-transaction --master-data=2备份时能自动带出这俩值 - 多个从库可以同时启动复制：
START REPLICA;（8.0.23+）或START SLAVE;（旧版），彼此完全独立
复制延迟怎么看：别只盯 Seconds_Behind_Master
Seconds_Behind_Master 显示为 NULL 或 0 不代表真同步完了。它只反映从库 SQL 线程执行到主库哪个位置，不包含网络传输时间、relay log 写盘延迟、甚至从库自身负载高导致 SQL 线程卡住的情况。
- 真正判断是否“追平”，得比对主库
SHOW MASTER STATUS的File/Position和从库SHOW REPLICA STATUS的Relay_Master_Log_File/Exec_Master_Log_Pos - 如果主库开了 GTID，更可靠的方式是看
Retrieved_Gtid_Set和Executed_Gtid_Set是否相等 - 一个从库延迟，不会拖慢其他从库——这是“一对多”能落地的前提，但前提是主库 IO 和网络扛得住并发 dump thread（每个从库连上来都会触发一个）
常见翻车点：主库负载突增、从库 auto-increment 冲突、跨版本兼容性
一对多看着简单，实际最容易在三个地方静默崩掉：
- 主库没做读写分离，所有从库一起拉 binlog，加上业务写入量大，
binlog写入 +dump thread读取可能打满磁盘 IO 或网络带宽，表现为主库响应变慢、部分从库报ERROR 2013 (HY000): Lost connection to MySQL server during query - 从库开了
auto_increment_increment和auto_increment_offset？千万别开。这是多主环形复制才用的，一对多场景下从库必须保持auto_increment_increment = 1，否则插入自增主键时可能冲突或跳号 - MySQL 5.7 主库 + 8.0 从库能同步，但反过来不行；GTID 模式下主从版本最好一致，否则
gtid_mode=ON兼容性容易出问题，比如 5.7 从库无法识别 8.0 主库生成的某些 GTID event
主库单点是硬伤，但“一对多”本身不解决高可用——它只是把数据分发出去，故障切换还得靠外部工具（如 MHA、Orchestrator）或应用层路由逻辑。这点很多人配置完就以为万事大吉，其实刚起步。
