Mysql 主从复制与读写分离

一、核心概念

（一）主从复制

定义：将主库（Master）的数据变更，通过二进制日志（binlog）同步到从库（Slave），实现数据实时备份与冗余。
核心作用：数据备份、读写分离、故障转移、负载均衡。
适用场景：高并发读场景、数据容灾、报表查询与业务数据分离。

（二）读写分离

定义：基于主从复制，将写操作（增删改）集中到主库，读操作（查询）分发到从库，平衡数据库负载。
核心价值：提升数据库并发处理能力，保障主库写性能，优化查询效率。

二、主从复制原理（三步核心）

复制流程
主库写日志：主库执行写操作后，将变更写入 binlog（二进制日志）。
从库拉取日志：从库通过 I/O 线程连接主库，拉取 binlog 并写入本地 relay log（中继日志）。
从库执行日志：从库通过 SQL 线程读取 relay log，按顺序执行其中的操作，完成数据同步。
关键配置（主库+从库）

（1）主库配置（my.cnf）

ini

mysqld

server-id = 1 # 主库唯一ID（从库ID需不同）

log_bin = mysql-bin # 开启binlog

binlog_format = ROW # 行级复制（推荐，数据同步更精准）

expire_logs_days = 7 # binlog自动清理天数

（2）从库配置（my.cnf）

ini

mysqld

server-id = 2 # 从库唯一ID（与主库不同）

relay_log = relay-bin # 开启中继日志

read_only = 1 # 从库只读（超级用户可忽略）

（3）主从库创建复制用户

sql

-- 主库创建复制专用用户

CREATE USER 'repl'@'从库IP' IDENTIFIED BY '123456';

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP';

FLUSH PRIVILEGES;

-- 查看主库binlog状态（记录File和Position，从库配置需用）

SHOW MASTER STATUS;

（4）从库关联主库

sql

-- 停止从库复制（若已开启）

STOP SLAVE;

-- 配置主库连接信息

CHANGE MASTER TO

MASTER_HOST='主库IP',

MASTER_USER='repl',

MASTER_PASSWORD='123456',

MASTER_LOG_FILE='mysql-bin.000001', -- 对应主库SHOW MASTER STATUS的File

MASTER_LOG_POS=156; -- 对应主库SHOW MASTER STATUS的Position

-- 启动从库复制

START SLAVE;

-- 查看复制状态（确认Slave_IO_Running和Slave_SQL_Running均为Yes）

SHOW SLAVE STATUS\G

三、主从复制常见模式

一主一从

架构：1台主库 + 1台从库
适用：小型项目、基础备份场景
优缺点：简单易维护；存在单点故障（主库挂了则业务中断）。

一主多从

架构：1台主库 + 多台从库
适用：中高并发读场景（如电商商品查询、后台报表）
核心作用：多从库分担读压力，可按从库角色分工（如1台做报表、1台做查询）。

主主复制（双主互备）

架构：2台主库互为主从（互相复制数据）
适用：高可用场景（避免单主库单点故障）
核心配置：两台库互设对方为从库，需注意自增主键冲突（需配置 auto_increment_offset 和 auto_increment_increment）。

四、读写分离实现方案

核心架构

plaintext

业务应用 → 中间件（读写分离代理） → 主库（写）、从库（读）

常用中间件

中间件特点适用场景

MyCat 开源、轻量、支持分库分表中小型项目、读写分离+分库分表

Atlas 基于MySQL官方协议，轻量纯读写分离场景

ProxySQL 高性能、支持监控、路由规则复杂大型项目、高并发、高可用场景

MySQL Router 官方官方工具，轻量无依赖小型项目、追求官方生态

读写分离核心规则
写操作：强制路由到主库（INSERT/UPDATE/DELETE 必须在主库执行，保证数据一致性）。
读操作：按需路由到从库（普通查询路由到从库，实时性要求极高的查询可路由到主库）。
从库负载均衡：多从库时，中间件按轮询、随机等策略分发读请求。
故障自动切换：中间件监控从库状态，若从库宕机，自动将读请求切换到其他从库/主库。
MyCat 读写分离配置示例（核心片段）

xml

</schema>

</user>

</rule>

五、关键问题与解决方案

主从数据不一致

原因：网络延迟、SQL执行失败、binlog同步异常、从库误操作。
解决方案：

监控复制状态（通过 SHOW SLAVE STATUS 或监控工具 Prometheus + Grafana）。
定期校验主从数据（使用工具 pt-table-checksum 、 mysqlcheck ）。
异常时快速修复：重新同步数据（如全量备份恢复从库 + 增量binlog补同步）。
读写分离延迟

原因：主库写压力大、网络带宽不足、从库性能较弱。
解决方案：

优化主库写性能（索引优化、SQL优化、分库分表）。
提升从库配置（CPU、内存、磁盘IO）。
缩短同步距离（主从库同机房、低延迟网络）。
实时性要求高的查询，强制路由到主库。
从库宕机

解决方案：

中间件自动屏蔽宕机从库，将读请求切换到其他从库。
修复从库后，重新同步数据（全量+增量），再加入集群。
主库宕机（故障转移）

手动方案：提升一台从库为新主库（修改中间件配置，切换写请求），其他从库同步新主库。
自动方案：搭配 MGR（MySQL Group Replication）、MHA、Keepalived 等工具，实现自动故障转移（RTO<5分钟）。

六、生产环境最佳实践

基础配置：

主从库版本一致（避免兼容性问题）。
开启binlog，且binlog_format=ROW（推荐）。
从库开启read_only=1（防止误写）。
多从库时，按角色分工（如报表从库、查询从库）。

监控与告警：

监控核心指标：主从延迟（Seconds_Behind_Master）、复制状态（IO/SQL线程运行状态）、数据库连接数、磁盘空间。
配置告警：当复制中断、延迟超过阈值时，及时通知运维。

数据安全：

复制用户仅授予最低权限（REPLICATION SLAVE）。
备份binlog和全量备份，异地存储。
定期测试数据恢复流程，确保故障时可快速恢复。

性能优化：

主库专注写操作，避免在主库执行复杂查询。
从库可开启慢查询日志，优化查询语句。
多从库时，合理分配读请求，避免单从库过载。