一、搭建准备工作

  • CentOS 操作系统, IP:192.168.32.129

  • CentOS 操作系统, IP:192.168.32.130

在以上两台CentOS操作系统中安装MySQL数据库

MySQL读写分离是一种通过​​将数据库的读操作与写操作分配到不同实例​​来提升系统性能和高可用性的架构设计。其核心思想是利用主库（Master）处理写操作（INSERT/UPDATE/DELETE），利用从库（Slave/Read Replica）处理读操作（SELECT），从而将读写压力分散到多个实例，缓解主库的单点瓶颈。

​​1、读写分离的核心依赖：主从复制（Master-Slave Replication）​​

读写分离的前提是主库与从库的数据保持​​实时或近实时同步​​，这一过程通过MySQL的​​主从复制机制​​实现。主从复制基于二进制日志（Binary Log, Binlog）完成，具体步骤如下：

1. 主库记录Binlog

主库在执行写操作（如INSERT/UPDATE/DELETE）时，会将所有修改数据的SQL语句或其对应的行变更记录写入二进制日志（Binlog）。Binlog是主从复制的核心数据源，记录了所有数据变更的“事件”。

2. 从库同步Binlog到中继日志（Relay Log）

从库通过​​IO线程​​连接到主库，请求主库发送未同步的Binlog事件。主库会将Binlog按顺序发送给从库，从库的IO线程将这些事件写入本地的​​中继日志（Relay Log）​​（一种临时存储的日志文件）。

3. 从库回放中继日志

从库的​​SQL线程​​会读取中继日志中的事件，并按照顺序在从库上执行这些事件（如重新执行INSERT/UPDATE/DELETE语句），从而将主库的数据变更同步到从库。最终，从库的数据与主库保持一致（可能存在微小延迟）。

​​2、读写分离的实现方式​​

读写分离的实现需解决两个关键问题：

  • ​​请求路由​​：根据操作类型（读/写）将请求分发到主库或从库；

  • ​​数据一致性​​：确保读操作尽可能获取最新数据（避免因主从延迟导致的脏读）。

常见的实现方式分为两类：

1. 应用层实现（手动路由）

在应用程序代码中直接判断操作类型，显式指定数据源：

  • 写操作（如INSERT/UPDATE/DELETE）：连接主库；

  • 读操作（如SELECT）：连接从库（可轮询多个从库实现负载均衡）。

​​优点​​：灵活性高，无需额外中间件；

​​缺点​​：与业务代码强耦合，维护成本高（如新增从库需修改代码），难以应对复杂场景（如事务中的读写混合操作）。

2. 中间件/代理层实现（自动路由）

通过独立的数据库中间件（Proxy）拦截SQL请求，自动判断操作类型并路由到对应的数据源。常见中间件包括：

  • ​​MyCat​​：基于Java的开源中间件，支持读写分离、分库分表；

  • ​​MaxScale​​：MySQL官方推荐的中间件，支持读写分离、负载均衡；

  • ​​ShardingSphere​​：Apache开源的数据库中间件，支持读写分离、分布式事务等；

​​云厂商方案​​：如阿里云RDS的读写分离代理、AWS RDS Proxy等。

​​优点​​：与应用解耦，支持动态扩缩从库，提供高可用、故障转移等能力；

​​缺点​​：引入额外组件，增加系统复杂度和运维成本。

​​3、读写分离的关键优化点​​

1. 主从延迟的处理

主从复制存在一定延迟（尤其是异步复制模式下），可能导致读从库时获取到旧数据。常见解决方案：

  • ​​强制读主库​​：对于时效性要求高的读操作（如刚提交的订单查询），直接路由到主库；

  • ​​从库延迟监控​​：通过监控工具（如Prometheus+Grafana）实时监控主从延迟，动态调整读请求的路由策略；

  • ​​半同步复制（Semi-Sync Replication）​​：主库提交事务前，等待至少一个从库确认已接收Binlog事件（非完全回放），降低数据不一致的概率；

  • ​​并行复制（多线程回放）​​：MySQL 5.7+支持从库的SQL线程多线程回放中继日志（基于库级别或事务组），缩短主从延迟。

2. 读请求的负载均衡

若有多个从库，需将读请求均匀分发到各个从库，避免单节点压力过大。常见策略：

  • ​​轮询（Round Robin）​​：按顺序依次分发请求；

  • ​​随机（Random）​​：随机选择一个从库；

  • ​​权重（Weighted）​​：根据从库的性能（如CPU、内存）分配不同权重，高性能从库处理更多请求；

  • ​​最少连接（Least Connections）​​：优先选择当前活跃连接数最少的从库。

3. 高可用与故障转移

主库或从库可能因故障宕机，需保证读写分离架构的可用性：

  • ​​主库高可用​​：通过MHA（Master High Availability）、Orchestrator等工具实现主库故障时自动切换（提升从库为主库）；

  • ​​从库冗余​​：部署多个从库，避免单个从库故障导致读服务不可用；

  • ​​中间件故障转移​​：中间件需支持自动检测主从状态，动态调整路由规则（如主库宕机后，将写请求路由到新主库）。

​​4、适用场景与局限性​​

​​适用场景​​

  • 读多写少的业务（如电商商品查询、新闻资讯浏览）；

  • 对数据实时性要求不高的读操作（如统计报表、历史数据查询）；

  • 需要横向扩展读能力的场景（通过添加从库提升读吞吐量）。

​​局限性​

  • 不适用于强一致性要求的场景（如实时转账后的余额查询）；

  • 主从复制延迟可能影响部分读操作的准确性；

  • 架构复杂度高于单库模式（需维护主从同步、中间件、故障转移等）。

二、搭建MySQL主从

​​1、配置主MySQL master

主 MySQL 配置

1

修改主MySQL my.cnf文件或my.ini 

#vi /etc/my.cnf
       [mysqld]
       log-bin=mysql-bin       //[必须]启用二进制日志

binlog_format=mixed   //二进制日志的格式，有三种：statement/row/mixed，这里使用mixed

1、statement：记录的是SQL的原文。好处是，不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。由于sql的执行是有上下文的，因此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。

2、row：不记录sql语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行的改动，基本是可以全部记下来但是由于很多操作，会导致大量行的改动(比如alter table)，因此这种模式的文件保存的信息太多，日志量太大。

3、mixed：一种折中的方案，普通操作使用statement记录，当无法使用statement的时候使用row

server-id=129           //[必须]服务器唯一ID，默认是1，一般取IP最后一段

2

重启MySQL服务：

# service mysqld restart

3

在主服务器上为从服务器分配一个账号，就像一把钥匙，从服务器拿着这个钥匙，才能到主服务器上来共享主服务器的日志文件。

mysql>GRANT replication slave ON *.* TO 'slave'@'%' identified by '1234';

replication slave 分配复制的权限

*.* 可以操作哪个数据库

slave 用户名

% 可以在所有的电脑中访问账户登录

1234 密码

4

查询配置状态

mysql> show master status;

zhumysql.png

​​2、配置从MySQL slave

配置从MySQL Slave

1

修改从MySQL my.cnf文件或my.ini

#vi /etc/my.cnf
       [mysqld]

       log-bin=mysql-bi

 //[不是必须]启用二进制日志

binlog_do_db=test

//同步的数据库

server-id=130        

说明：

# 不同步哪些数据库  

binlog-ignore-db = mysql  

binlog-ignore-db = test  

binlog-ignore-db = information_schema  

# 只同步哪些数据库，除此之外，其他不同步  

binlog-do-db = game  

2

重启MySQL服务：

# service mysqld restart

3

关闭slave（一定要先关闭）

命令：

mysql>stop slave;

4

开始配置

mysql>change master to

master_host='192.168.32.129',

master_user='slave',

master_password='123456',

master_log_file='mysql-bin.000001',

master_log_pos=154;

参数解释：MASTER_HOST  :  设置要连接的主服务器的ip地址

　　　　  MASTER_USER  :  设置要连接的主服务器的用户名

　　　　  MASTER_PASSWORD  :  设置要连接的主服务器的密码

   　　　　MASTER_LOG_FILE  :  设置要连接的主服务器的bin日志的日志名称，即第3步得到的信息

   　　　　MASTER_LOG_POS  :  设置要连接的主服务器的bin日志的记录位置，即第3步得到的信息，（这里注意，最后一项不需要加引号。否则配置失败）

5

启动slave同步

mysql>start slave;

6

检查从服务器复制功能状态

mysql> show slave status;

图片2.png

7

创建一个只读帐号

GRANT Select ON . TO reader@"%"  IDENTIFIED BY "123456"

配置完成后可以连接测试，在主数据库中插入一条语句，在从数据库中是否有数据信息。