MySQL 主从架构（基于Binlog）
一、核心原理
MySQL主从架构的核心是基于Binlog（二进制日志） 实现数据同步：
- 主库（Master）将所有数据修改操作（增删改）记录到Binlog；
- 从库（Slave）通过IO线程连接主库，读取主库的Binlog并写入本地的中继日志（Relay Log）；
- 从库的SQL线程读取中继日志，重放其中的操作，最终实现从库数据与主库一致。
二、典型架构及架构图
1. 核心架构类型
| 架构类型 | 适用场景 | 核心特点 |
|---|
| 一主一从 | 中小规模业务、数据备份 | 架构简单，成本低，主库故障可切换到从库 |
| 一主多从 | 读多写少、高并发查询 | 分散读压力，多个从库分担查询请求 |
| 多主一从 | 多业务中心写入、数据汇总 | 多个主库写入，一个从库汇总数据 |
| 多主多从 | 大型分布式系统、异地多活 | 高可用、高扩展，支持异地部署 |
2. 架构图
（1）一主一从架构图
flowchart TD
A["客户端"] -->|所有写操作| B["Master主库"]
A -->|所有读操作| C["Slave从库"]
B -->|Binlog日志| D["IO线程<Br/>（从库）"]
D -->|写入Relay Log| E["Relay Log<Br/>（中继日志）"]
E -->|重放操作| F["SQL线程<Br/>（从库）"]
F --> C
note1["注：主库负责写，从库仅提供读服务"] --> C
（2）一主多从架构图
flowchart TD
A["客户端"] -->|所有写操作| B["Master主库"]
A -->|读操作负载均衡| C["Slave从库1"]
A -->|读操作负载均衡| D["Slave从库2"]
A -->|读操作负载均衡| E["Slave从库3"]
B -->|Binlog日志| C1["IO线程<Br/>（从库1）"]
B -->|Binlog日志| D1["IO线程<Br/>（从库2）"]
B -->|Binlog日志| E1["IO线程<Br/>（从库3）"]
C1 -->|写入Relay Log| C2["Relay Log<Br/>（从库1）"]
D1 -->|写入Relay Log| D2["Relay Log<Br/>（从库2）"]
E1 -->|写入Relay Log| E2["Relay Log<Br/>（从库3）"]
C2 -->|重放操作| C3["SQL线程<Br/>（从库1）"]
D2 -->|重放操作| D3["SQL线程<Br/>（从库2）"]
E2 -->|重放操作| E3["SQL线程<Br/>（从库3）"]
C3 --> C
D3 --> D
E3 --> E
note1["注：主库仅处理写，多个从库分担读请求"] --> B
三、关键配置项（以MySQL 8.0为例）
1. 主库（Master）配置（my.cnf/my.ini）
[mysqld]
log_bin = /var/lib/mysql/mysql-bin
binlog_format = ROW
server_id = 1
binlog_do_db = test
binlog_ignore_db = mysql
expire_logs_days = 7
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
2. 从库（Slave）配置
[mysqld]
server_id = 2
relay_log = /var/lib/mysql/relay-bin
read_only = 1
super_read_only = 1
skip_log_bin = 1
innodb_read_only = 1
log_slave_updates = 0
slave_skip_errors = 1062
master_info_repository = TABLE
relay_log_info_repository = TABLE
3. 从库只读配置补充说明
| 配置项 | 作用说明 | 适用场景 |
|---|
read_only = 1 | 普通用户无法写，拥有SUPER权限的用户仍可写（如运维同步账号） | 测试/预生产环境，需运维写操作 |
super_read_only = 1 | 所有用户（包括SUPER权限）均无法写，彻底禁止从库写入 | 生产环境（纯读从库） |
innodb_read_only = 1 | 针对InnoDB存储引擎的只读限制，防止通过特殊方式修改InnoDB表数据 | 生产环境加固 |
skip_log_bin = 1 | 关闭从库Binlog，避免从库因误写产生无用日志，同时节省磁盘IO | 纯读从库（非级联主库） |
4. 主从关联配置（SQL命令）
CREATE USER 'repl'@'从库IP' IDENTIFIED BY '同步密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;
CHANGE MASTER TO
MASTER_HOST='主库IP',
MASTER_USER='repl',
MASTER_PASSWORD='同步密码',
MASTER_LOG_FILE='主库Binlog文件名（如mysql-bin.000001）',
MASTER_LOG_POS=主库Binlog位置（如156）;
START SLAVE;
SHOW SLAVE STATUS\G;
SHOW VARIABLES LIKE '%read_only%';
INSERT INTO test.t1 (id) VALUES (1);
四、优缺点分析
1. 优点
| 优势点 | 具体说明 |
|---|
| 提高读性能 | 多从库分担查询压力，支持高并发读 |
| 数据备份 | 从库可作为主库的热备，故障时快速切换 |
| 高可用 | 主库故障后，可将从库提升为主库 |
| 资源隔离 | 主库专注写操作，从库专注读操作，资源利用更高效 |
| 扩展性好 | 可按需增加从库数量，水平扩展读能力 |
2. 缺点
| 缺点点 | 解决方案 |
|---|
| 主从延迟 | 开启半同步复制、优化从库SQL线程、监控延迟指标 |
| 架构复杂度提升 | 标准化配置模板、自动化运维工具（如Ansible） |
| 数据一致性风险 | 严格限制从库写入、定期校验主从数据（pt-table-checksum） |
| 切换成本 | 制定切换预案、使用MGR（MySQL Group Replication）简化切换 |
| 存储成本增加 | 按需规划从库数量，采用云数据库弹性扩容 |
五、应用场景
| 场景类型 | 适配性 | 核心价值 |
|---|
| 读多写少的业务（如电商、资讯） | 高 | 分散读压力，提升查询响应速度 |
| 数据备份与灾备 | 高 | 从库实时备份，主库故障快速恢复 |
| 高并发查询场景（如秒杀、报表） | 高 | 多从库分担统计/查询压力 |
| 异地多活部署 | 中 | 跨地域部署主从，降低地域故障影响 |
| 写密集型业务（如金融交易） | 低 | 主从延迟可能导致数据不一致，需谨慎 |
六、优化建议
- 性能优化：
- Binlog使用ROW格式，减少同步歧义；
- 从库关闭慢查询日志、不必要的日志记录，降低资源消耗；
- 主从库均开启索引优化，提升查询/同步效率。
- 稳定性优化：
- 开启半同步复制（
plugin-load-add = rpl_semi_sync_master.so）；
- 监控同步状态（Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master），异常时及时告警；
- 定期备份Binlog和中继日志，防止数据丢失。
- 只读加固优化：
- 生产环境强制开启
super_read_only = 1，彻底禁止从库写入；
- 限制从库账号权限，仅授予SELECT权限，避免误操作；
- 定期检查从库只读配置状态，防止配置被篡改。
总结
- MySQL主从架构基于Binlog实现数据同步，核心是主库写、从库读，架构图清晰展示了IO线程和SQL线程的同步流程；
- 从库只读需通过
read_only=1（基础）或者super_read_only=1（严格）+innodb_read_only=1（加固）多层配置；
- 主从架构核心价值是提升读性能、实现数据备份，适合读多写少场景，需重点监控主从延迟和只读配置状态。
