如何搭建MySQL一主多从复制架构

一主多从需主库一次配置但满足多从要求，各从库须有唯一server-id、独立relay-log路径、IP限定复制账号，并优先从现有从库克隆数据初始化，避免主库压力。

一主多从不是简单地把“一主一从”复制几遍，而是要解决多个从库共用同一套 binlog 流时的资源竞争、权限隔离、数据初始一致性、以及后续监控维护成本上升的问题。核心在于：主库配置一次即可，但每个从库必须有独立 server-id、独立中继日志路径、独立复制账号（或严格限制 IP），且初始化方式需避免对主库造成压力。

主库配置必须支持多个从库同时拉取 binlog

主库只需一次配置，但参数必须满足多从场景的基本要求：

1. server-id 必须唯一且非 0（如设为 1）——这是整个集群的锚点，不能和任何从库重复
2. log_bin 必须启用（如 mysql-bin），且磁盘空间充足；建议配 expire_logs_days = 7 防止日志堆积
3. binlog_format 强烈推荐设为 ROW，避免语句级复制在函数、临时表、非确定性 SQL 下的数据不一致
4. 不要用 binlog-do-db 或 binlog-ignore-db 做库级过滤——它们在多从、跨库事务下行为不可靠，改用从库端的 replicate-do-db 更可控
5. 确认 max_connections 足够（默认 151 往往不够），因为每个从库至少占用 1 个连接，N 个从库就要预留 N+20 以上

每个从库的 server-id 和 relay log 路径必须互不冲突

从库之间若 server-id 相同，会导致主库无法区分它们，出现 “Duplicate server id” 错误，甚至中断所有复制链路。

1. server-id 推荐用 IP 尾数（如 192.168.1.11 → 11）或递增编号（101, 102, 103），严禁重复
2. relay-log 必须显式指定路径和前缀，例如 /var/lib/mysql/relaylog/slave1-relay，否则默认名是 hostname-relay-bin，在主机名相同或克隆环境里极易撞名
3. read_only = ON 是强制项，防止应用误写从库导致主从不一致；MySQL 8.0 还建议加 super_read_only = ON
4. 若启用 GTID（强烈推荐），则所有从库必须统一开启：gtid_mode = ON + enforce_gtid_consistency = ON

复制账号要按从库 IP 精确授权，别复用通配符账号

用 'repl'@'%' 给所有从库授权看似方便，实则埋下严重隐患：任意能连上主库的机器都可发起复制，且无法区分哪个从库出问题。

1. 为每个从库单独建账号，IP 明确限定，例如：CREATE USER 'repl_slave1'@'192.168.1.11' IDENTIFIED BY 'pwd1';
2. 授最小权限：GRANT REPLICATION SLAVE ON *.* TO 'repl_slave1'@'192.168.1.11';
3. 如果从库 IP 动态（如云环境），至少用子网段限制：'repl_slave2'@'192.168.1.%'，而非 '%'
4. MySQL 8.0 注意认证插件：若主库用 caching_sha2_password，从库连接时需确保客户端支持，否则报 Plugin caching_sha2_password could not be loaded

初始化从库数据必须保证全局一致性，禁止直接 mysqldump 主库

当已有 1 个从库在运行时，新增第 2、第 3 个从库，绝不能重新执行一遍 mysqldump --master-data=2 ——这会锁主库、拖慢线上业务，且导出位置已过期。

1. 首选方案：从**现有从库**克隆数据（冷备或 Percona XtraBackup 热备），完全避开主库
2. 次选方案：用主库的 SHOW MASTER STATUS 当前位点，配合 mysqldump --single-transaction --skip-lock-tables 导出（仅适用于小数据量）
3. 严禁在 dump 过程中执行 DDL（如 ALTER TABLE），否则 --single-transaction 失效，导致备份不一致
4. 导入后，从库启动前务必检查 SELECT @@global.gtid_executed;（GTID 模式）或 SHOW MASTER STATUS;（位点模式）是否与预期初始状态匹配

最易被忽略的一点：一主多从后，SHOW SLAVE STATUSG 输出里的 Seconds_Behind_Master 是单个从库自己的延迟，不代表整体；你得逐个查，或用 pt-heartbeat 统一监控所有从库的真实 lag。没有集中监控，等于没真正落地一主多从。