主库必须开启binlog并设唯一server-id；每从库需独立配置server-id和CHANGE MASTER TO；切换主库前须确保GTID模式一致或binlog位点对齐。
主库必须开启 binlog 并设置唯一 server-id
MySQL 主从复制依赖 binlog，主库不启用就无法同步。确认 my.cnf 中有以下配置：
-
log-bin = /var/lib/mysql/mysql-bin（路径可自定义，但需确保目录可写） -
server-id = 1（必须是非 0 整数，且全集群唯一） -
binlog-format = ROW（推荐，避免语句级复制在从库执行偏差）
改完重启 MySQL，并用 SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'server_id'; 验证。常见错误是改了配置但没重启，或 server-id 在多台机器上重复（比如都设成 1），导致从库拒绝连接。
每个从库都要独立配置 server-id 和 CHANGE MASTER TO
多从不是“一配全通”，每台从库必须有自己唯一的 server-id（如 11、12、13），且 CHANGE MASTER TO 命令中指定的主库 binlog 文件名和位置必须来自同一时刻的 SHOW MASTER STATUS 快照——不能拿主库不同时间点的两个结果分别配给两个从库，否则数据不一致。
实操建议：
- 先在主库执行
FLUSH TABLES WITH READ LOCK;，再SHOW MASTER STATUS;记下File和Position - 用
mysqldump --all-databases --master-data=2 --single-transaction导出并导入到各从库（--master-data=2会把 binlog 位置写进 dump 文件） - 解锁：主库执行
UNLOCK TABLES; - 每台从库单独执行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154, ...
启动多从后要逐个检查 Seconds_Behind_Master 是否稳定
运行 START SLAVE; 后，别只看 Slave_IO_Running 和 Slave_SQL_Running 是 Yes 就以为完事。真正关键的是 Seconds_Behind_Master：
- 持续为 0：正常
- 缓慢增长：可能主库写入压力大，或从库磁盘 I/O 慢、SQL 线程单线程瓶颈（尤其 MySQL 5.7 及以前）
- 突然跳变为 NULL 或负数：通常表示 SQL 线程报错中断，立刻查
SHOW SLAVE STATUS\G中的Last_SQL_Error
多从环境下，某一台从库延迟高不会影响其他从库，但容易被忽略。建议用脚本定时轮询所有从库的该字段，而非只盯一台。
主库崩溃后切换要注意 GTID 和 binlog 位点对齐
多从架构下做主从切换，最易踩的坑是没统一 GTID 模式或没校验 binlog 位点。如果主库已启用 gtid_mode = ON，所有从库也必须开启，否则 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 会失败；如果用传统位点方式，则必须确认所有从库的 Relay_Master_Log_File 和 Exec_Master_Log_Pos 完全一致，才能选其中一台升主——否则缺数据。
简单判断方法：
- 查所有从库：
SELECT @@gtid_mode;，不全是 ON 就别用自动定位 - 查所有从库：
SHOW SLAVE STATUS\G，比对Relay_Master_Log_File和Exec_Master_Log_Pos是否完全相同
实际生产中，多从之间 binlog 进度天然存在微小差异，靠人工比对不可靠，需要用工具（如 pt-heartbeat）或监控系统持续跟踪。
