MySQL主从复制与读写分离

什么是读写分离？

读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、

DELETE）而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步

到集群中的从数据库。

为什么要读写分离呢？

因为数据库的“写”（写10000条数据可能要3分钟）操作是比较耗时的。

但是数据库的“读”（读10000条数据可能只要5秒钟）。

所以读写分离，解决的是，数据库的写入，影响了查询的效率。

什么时候要读写分离？

数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用。

利用数据库主从同步，再通过读写分离可以分担数据库压力，提高性能。

主从复制与读写分离

在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无

论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复

制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。有点类似于rsync，但是不

同的是rsync是对磁盘文件做备份，而mysql主从复制是对数据库中的数据、语句做备份。

mysql支持的复制类型

STATEMENT：基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，执行

效率高。

ROW：基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。MySQL

5.7.7 之后，binlog 的存储格式默认 Row

MIXED：混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会

采用基于行的复制。

主从复制的工作过程

Master节点将数据的改变记录成二进制日志（bin log），当Master上的数据发生改变时，则将其改

变写入二进制日志中。

Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，

则开始一个I/O线程请求 Master的二进制事件。

同时Master节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至Slave节

点本地的中继日志（Relay log）中，Slave节点将启动SQL线程从中继日志中读取二进制日志，在

本地重放，即解析成 sql 语句逐一执行，使得其数据和 Master节点的保持一致，最后I/O线程和

SQL线程将进入睡眠状态，等待下一次被唤醒。

注：

●中继日志通常会位于 OS 缓存中，所以中继日志的开销很小。

●复制过程有一个很重要的限制，即复制在 Slave上是串行化的，也就是说 Master上的并行更新操

作不能在 Slave上并行操作。

一主俩从 

7-5主服务器

7-3/4从服务器

初始化操作

同步时间

使用脚本每半小时进行时间同步

 

开启chrony服务

查看配置文件

 centos的时间源服务器

 进行注释并添加国内源

 重启

----Mysql主从服务器时间同步----

##主服务器设置##

 

登录并创建库

授权

 

----从服务器的mysql配置----

 

 

切换从服务器

检查

切换7-4服务器重复操作

回主服务器7-5查看库

 主库创建表

从库都自动出现

主库定义表数据

插入数据

从库自动出现

//主数据库配置

//从数据库配置（7-3/4都做）

 

主库发生变化

参数说明：

Rpl_semi_sync_master_clients                      #半同步复制客户端的个数

Rpl_semi_sync_master_net_avg_wait_time            #平均等待时间（默认毫秒）

Rpl_semi_sync_master_net_wait_time                #总共等待时间

Rpl_semi_sync_master_net_waits                    #等待次数

Rpl_semi_sync_master_no_times                     #关闭半同步复制的次数

Rpl_semi_sync_master_no_tx                        #表示没有成功接收slave提交的次数

Rpl_semi_sync_master_status                       #表示当前是异步模式还是半同步模式，on为半同步

Rpl_semi_sync_master_timefunc_failures            #调用时间函数失败的次数

Rpl_semi_sync_master_tx_avg_wait_time             #事物的平均传输时间

Rpl_semi_sync_master_tx_wait_time                 #事物的总共传输时间

Rpl_semi_sync_master_tx_waits                     #事物等待次数

Rpl_semi_sync_master_wait_pos_backtraverse        #可以理解为"后来的先到了，而先来的还没

                                                                                        有到的次数"

Rpl_semi_sync_master_wait_sessions           #当前有多少个session因为slave的回复而造成等待

Rpl_semi_sync_master_yes_tx                       #成功接受到slave事物回复的次数

当半同步复制发生超时（由rpl_semi_sync_master_timeout参数控制，默认为10000ms，即

10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。

当 master dump 线程发送完一个事务的所有事件之后，如果在 rpl_semi_sync_master_timeout

内，收到了从库的响应， 则主从又重新恢复为半同步复制。

主从复制不一致问题的解决：

1）先进入主库，进行锁表，防止数据写入

flush tables with read lock;

set gloabl read_only=1;

2）进行数据全量备份

mysqldump -u root -p密码 库名 表名 > XXX.sql

3）使用scp命令把备份文件传到从库机器，进行数据恢复

scp XXX.sql  从库IP:目录/

stop slave;

mysql -u root -p密码 < XXX.sql

4）使用 change master to 重新做主从复制

change master to master_host='主库IP', master_port=3306, master_user='用户名',

master_password='密码', master_log_file='二进制文件', master_log_pos=二进制事件位置;

对数据库表进行锁操作

主从复制的同步模式：

1）异步复制     主库在执行完客户端提交的事务后就会立即响应给客户端

2）半同步复制   主库在执行完客户端提交的事务后，只要等待一个从库返回响应给主库，才会响

应给客户端

3）全同步复制   主库在执行完客户端提交的事务后，要等待所有从库返回都响应给主库，才会响

应给客户端

在什么情况下半同步复制会降为异步复制？

当主库在半同步复制超时时间内（rpl_semi_sync_master_timeout）没有收到从库的响应，就会自

动降为半同步复制。

当主库发送完一个事务事件后，主库在超时时间内收到了从库的响应，就会又恢复为半同步复制。

再启动一台服务器做读写分离

安装配置

赋予权限并执行

一直回车 

转移指定目录

创建目录

解压文件

 编译文件

 检查

修改配置文件

 

修改配置文件

 

先给主从服务器创建用户并授权（三台都做）

 

 验证操作