不需要停主库、不中断业务，但每新增一个从库都必须独立完成配置隔离、账号授权和CHANGE MASTER三步，且server-id绝对不能重复。
新增从库前必须确认的主库状态
主库不是“设好就能加从库”，它得处于可被安全接入的状态：
-
show variables like 'log_bin'返回ON—— 否则复制根本无法启动 -
show variables like 'server_id'值必须是唯一整数（比如1），且不能和任何将要添加的从库冲突 -
show master status输出的File和Position是新从库同步的起点，但注意：如果主库开启了 GTID（gtid_mode=ON），后续要用CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1+START SLAVE，而不是靠文件+位置 - 防火墙需放行主库
3306端口（或自定义端口）给新从库 IP，否则ERROR 2003 (HY000): Can't connect to MySQL server
每个新从库必须单独执行的初始化操作
不能复制已有从库的配置文件或数据目录，否则会因 server-id 冲突或 relay log 混乱导致同步失败：
- 修改新从库的
/etc/my.cnf，确保server-id全局唯一（例如已有从库是2和3，新从库设为4） - 启动前清空旧数据目录（如
/var/lib/mysql），或用mysqld --initialize-insecure重置（生产环境建议用备份恢复，避免 schema 不一致） - 创建专用复制账号时，host 部分不要写
'%'，而应限定为该从库 IP，例如'repl'@'192.168.188.12'—— 减少暴露面，也方便排查连接来源 - 执行
CHANGE MASTER TO时，master_log_file和master_log_pos必须严格对应主库当前show master status输出，哪怕只差 1 字节，START SLAVE后也会报Could not find first log file name in binary log index file
常见同步失败现象及定位命令
新加从库启动后 SHOW SLAVE STATUS\G 是唯一可信依据，别只看 Slave_IO_Running 和 Slave_SQL_Running 是 Yes：
- 如果
Seconds_Behind_Master: NULL，先查Slave_IO_State是否卡在Connecting to master—— 大概率网络或账号密码错 - 如果
Seconds_Behind_Master持续增长，检查Relay_Log_Space是否暴涨，再看Retrieved_Gtid_Set和Executed_Gtid_Set是否有 gap（GTID 模式下） -
Last_IO_Error或Last_SQL_Error字段里藏了真实原因，例如error 1062: Duplicate entry 'xxx' for key 'PRIMARY'表示从库已有脏数据，需人工干预或跳过（SET GLOBAL sql_slave_skip_counter = 1仅限非 GTID） - 别忽略
Master_Host和Master_User是否显示正确——曾有人复制配置时漏改master_host，结果所有从库连到了同一个旧从库上
Seconds_Behind_Master 和 Relay_Log_Space。延迟一旦超过阈值，应用读到的就是过期数据；relay log 占满磁盘，整个复制链就断了。这些监控项必须纳入你的巡检 checklist，而不是等告警才反应。 
