一主多从需主库一次配置但满足多从要求，各从库须有唯一server-id、独立relay-log路径、IP限定复制账号，并优先从现有从库克隆数据初始化，避免主库压力。
一主多从不是简单地把“一主一从”复制几遍，而是要解决多个从库共用同一套 binlog 流时的资源竞争、权限隔离、数据初始一致性、以及后续监控维护成本上升的问题。核心在于：主库配置一次即可，但每个从库必须有独立 server-id、独立中继日志路径、独立复制账号（或严格限制 IP），且初始化方式需避免对主库造成压力。
主库配置必须支持多个从库同时拉取 binlog
主库只需一次配置，但参数必须满足多从场景的基本要求：
-
server-id必须唯一且非 0（如设为1）——这是整个集群的锚点，不能和任何从库重复 -
log_bin必须启用（如mysql-bin），且磁盘空间充足；建议配expire_logs_days = 7防止日志堆积 -
binlog_format强烈推荐设为ROW，避免语句级复制在函数、临时表、非确定性 SQL 下的数据不一致 - 不要用
binlog-do-db或binlog-ignore-db做库级过滤——它们在多从、跨库事务下行为不可靠，改用从库端的replicate-do-db更可控 - 确认
max_connections足够（默认 151 往往不够），因为每个从库至少占用 1 个连接，N 个从库就要预留 N+20 以上
每个从库的 server-id 和 relay log 路径必须互不冲突
从库之间若 server-id 相同，会导致主库无法区分它们，出现 “Duplicate server id” 错误，甚至中断所有复制链路。
-
server-id推荐用 IP 尾数（如192.168.1.11→11）或递增编号（101,102,103），严禁重复 -
relay-log必须显式指定路径和前缀，例如/var/lib/mysql/relaylog/slave1-relay，否则默认名是hostname-relay-bin，在主机名相同或克隆环境里极易撞名 -
read_only = ON是强制项，防止应用误写从库导致主从不一致；MySQL 8.0 还建议加super_read_only = ON - 若启用 GTID（强烈推荐），则所有从库必须统一开启：
gtid_mode = ON+enforce_gtid_consistency = ON
复制账号要按从库 IP 精确授权，别复用通配符账号
用 'repl'@'%' 给所有从库授权看似方便，实则埋下严重隐患：任意能连上主库的机器都可发起复制，且无法区分哪个从库出问题。
- 为每个从库单独建账号，IP 明确限定，例如：
CREATE USER 'repl_slave1'@'192.168.1.11' IDENTIFIED BY 'pwd1'; - 授最小权限：
GRANT REPLICATION SLAVE ON *.* TO 'repl_slave1'@'192.168.1.11'; - 如果从库 IP 动态（如云环境），至少用子网段限制：
'repl_slave2'@'192.168.1.%'，而非'%' - MySQL 8.0 注意认证插件：若主库用
caching_sha2_password，从库连接时需确保客户端支持，否则报Plugin caching_sha2_password could not be loaded
初始化从库数据必须保证全局一致性，禁止直接 mysqldump 主库
当已有 1 个从库在运行时，新增第 2、第 3 个从库，绝不能重新执行一遍 mysqldump --master-data=2 ——这会锁主库、拖慢线上业务，且导出位置已过期。
- 首选方案：从**现有从库**克隆数据（冷备或 Percona XtraBackup 热备），完全避开主库
- 次选方案：用主库的
SHOW MASTER STATUS当前位点，配合mysqldump --single-transaction --skip-lock-tables导出（仅适用于小数据量） - 严禁在 dump 过程中执行 DDL（如
ALTER TABLE），否则--single-transaction失效，导致备份不一致 - 导入后，从库启动前务必检查
SELECT @@global.gtid_executed;（GTID 模式）或SHOW MASTER STATUS;（位点模式）是否与预期初始状态匹配
最易被忽略的一点：一主多从后，SHOW SLAVE STATUS\G 输出里的 Seconds_Behind_Master 是单个从库自己的延迟，不代表整体；你得逐个查，或用 pt-heartbeat 统一监控所有从库的真实 lag。没有集中监控，等于没真正落地一主多从。
