目录

1. 主从复制和读写分离

2. mysql 支持的复制类型

3.架构图

 一.主从复制

1.主从复制的定义 

2.主从复制的过程 

中继日志（Relay Log）：

优点：

3.为什么要复制

4.谁复制谁

5.数据放在什么地方

6.主从复制出现的问题 

7.解决方法 

8.主从复制搭建 

 设置主服务器名字和时间同步

设置 从服务器时间同步和别名

 设置主服务器mysql

设置从服务器的mysql

 验证

9.总结

MySQL 主从复制的几个同步模式 

二.读写分离 

1.什么是读写分离

2.读写分离的原因 

3.进行读写分离的情况

4.主从复制与读写分离的联系 

5.目前较为常见的 MySQL 读写分离分为以下两种： 

基于程序代码内部实现

基于中间代理层实现 

6.基于中间件Amoeba搭建MySQL读写分离 

 7.搭建读写分录

环境准备

安装Java环境 

安装Amoeba软件 

配置 amoeba 读写分离

主服务器授权：

从服务器授权 

​编辑  Aomeba 主机 dbServers.xml 配置文件的设置：

​编辑 启动

查看端口

​编辑

客户端测试 

安装mariadb 

 启动

连接数据库

​编辑 三.总结

① 主从同步复制原理

② 读写分离使用什么方式

③ 如何查看主从同步状态是否成功 

④ 如果I/O不是yes，如何排查 

⑤ show slave status 可以看到哪些信息

⑥ 主从复制慢（延迟）会有哪些可能？怎么解决？

---

1. 主从复制和读写分离

在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。有点类似于rsync，但是不同的是rsync是对磁盘文件做备份，而mysql主从复制是对数据库中的数据、语句做备份。

2. mysql 支持的复制类型

① STATEMENT

基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高。

② ROW

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

③ MIXED

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

对比：

STATEMENT：

• 传输效率高，减少延迟。
• 在从库更新不存在的记录时，语句赋值不会失败。而行复制会导致失败，从而更早发现主从之间的不一致。

• 设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录

row：

• 不需要执行查询计划。
• 不知道执行的到底是什么语句。

3.架构图

主从复制是为了解决生产环境中的高并发状况 

 一.主从复制

1.主从复制的定义 

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库。在赋值过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。
当一台从服务器连接到主服务器时，从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从哪个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新

2.主从复制的过程 

• Master节点将数据的改变记录成二进制日志（bin log），当Master上的数据发生改变时，则将其改变写入二进制日志中。
• Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求 Master的二进制事件。
• 同时Master节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至Slave节点本地的中继日志（Relay log）中，Slave节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，即解析成 sql 语句逐一执行，使得其数据和 Master节点的保持一致，最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒。

Dump thread线程用于监听IO线程的请求，将二进制的日志文件中更新的数据发送给Slave从服务器进行操作  

• 中继日志通常会位于 OS 缓存中，所以中继日志的开销很小。
• 复制过程有一个很重要的限制，即复制在 Slave上是串行化的，也就是说 Master上的并行更新操作不能在 Slave上并行操作。

主从复制过程的简易理解：

• 主服务器Master通知存储引擎，进行存储数据，Dump thread备份线程开始备份数据，将备份的数据文件保存为binlog二进制日志文件格式；
• 从服务器请求与主服务器进行数据同步，Dump thread线程响应从服务器的请求，将binlog二进制日志文件传输给从服务器，从服务器接收到二进制日志文件并将二进制日志文件存放于relaylog中继日志文件中（中继日志文件可以理解为一个存放数据的站点），因为数据库不能直接处理中继日志的数据文件，要使用SQL语句进行读取，使得中继日志中存放的日志文件便于数据库进行读取拷贝数据，SQL语句解译后将数据存放于数据库中，至此主从复制过程结束。

总结：两个日志（二进制日志binlog、中继日志relaylog），三个线程（Dump thread、IO thread、SQL thread）

中继日志（Relay Log）：

在MySQL的主从复制架构中，中继日志（Relay Log）扮演着至关重要的角色。当一个MySQL服务器充当从服务器时，它会从主服务器接收二进制日志（Binlog）事件，并将这些事件存储在其自身的中继日志中。中继日志的主要功能是：

1. 存储主服务器的更改： 主服务器的二进制日志记录了所有的数据变更事件，这些事件通过主从复制传输到从服务器后，被暂时存储在中继日志中。

2. 异步处理： 从服务器不需要实时同步主服务器的所有更改，而是先将这些更改存放在中继日志中，然后按照事件发生的顺序依次执行。

3. 故障恢复和数据一致性： 如果从服务器在处理过程中发生中断，重启后可以从上次执行完的位置继续读取并执行中继日志中的事件，从而保持与主服务器数据的一致性。
4. 多级复制： 在复杂的多级复制架构中，从服务器也会将接收到的主服务器二进制日志事件转存为自己的中继日志，以便传递给下一级别的从服务器。

中继日志文件通常位于从服务器的特定目录下，并按照一定的命名规则（如主机名加时间戳）创建。MySQL的IO线程负责从主服务器读取二进制日志事件并写入中继日志，SQL线程则负责读取中继日志并执行这些事件以更新从服务器的数据。

优点：

• 数据分布：通过复制将数据分布到不同地理位置

• 负载均衡：读写分离以及将读负载到多台从库

• 备份：可作为实时备份

• 高可用性：利用主主复制实现高可用

3.为什么要复制

保证数据的完整性

4.谁复制谁

slave(从) 角色复制 master(主)角色的数据

5.数据放在什么地方

二进制文件 mysql-bin-000001--->记录完整的sql，slave复制二进制文件到本地节点，保存为中继日志文件方式，最后基于这个中继日志进行恢复操作，将执行的 sql 同步到自己的数据库当中做中达到与 master 数据一致性

6.主从复制出现的问题 

• Master服务器高并发，形成大量事务
• 网络延迟
• 主从硬件设备导致（CPU、内存IO、硬盘IO）
• 异步复制

7.解决方法 

• 从库优化Mysql参数。比如增大InnoDB_buffer_pool_size（内存池）让更多操作在Mysql内存中完成，减少磁盘操作
• 从库优化高性能主机。比如高性能的CPU、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了I/O读写性。
• 从库优化SSD磁盘
• 网络优化，避免跨机房实现同步（主从复制尽量选择在同一局域网内

8.主从复制搭建 

关闭三台服务器的防火墙和防护

 设置主服务器名字和时间同步

root@localhost ~]# hostnamectl set-hostname master
#修改名字
[root@localhost ~]# bash
#刷新

 

[root@master ~]# yum install ntp -y
#安装ntp做时间同步

[root@master ~]#vim /etc/ntp.conf
 
server 127.127.10.0
#设置本地源是时钟源
fudge 127.127.10.0 stratum 8
#设置时间层级为8（限制在15内）

[root@master ~]#service ntpd start
#启动ntp服务

设置 从服务器时间同步和别名

 

启动服务 

 

 和主开启时间同步

/usr/sbin/ntpdate 192.168.209.60
#和mater开启时间同步

创建计划任务，半小时执行一次 

[root@slave1 ~]#crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.44.60
#创建计划任务，每半小时执行一次时间同步
 

查看计划任务 

另一台slave2同理 

 设置主服务器mysql

编辑mysql配置文件

[root@master ~]#vim /etc/my.cnf
 
[mysqld]
server-id = 1 
#指定服务id号，master和其他两台slave都要不一样
log-bin=master-bin
#开启二进制日志
binlog_format=MIXED
#指定二进制日志的记录形式为mixed
log-slave-updates=true
#允许slave从master复制数据时写入

重启服务 

[root@master ~]# systemctl restart mysqld.service 
#重启服务

 

进入mysql设置 

mysql> grant replication slave on *.* to 'myslave'@'192.168.209.%' identified by '123456';
#给从服务器授权
 
mysql> flush privileges;
#刷新

show master status;
#查看偏移量

设置从服务器的mysql

vim /etc/my.cnf
server-id = 2                                
#修改，注意id与Master的不同，两个Slave的id也要不同
relay-log=relay-log-bin                        
#添加，开启中继日志，从主服务器上同步日志文件记录到本地
relay-log-index=slave-relay-bin.index        
#添加，定义中继日志文件的位置和名称，一般和relay-log在同一目录
relay_log_recovery = 1                      
#选配项
#当 slave 从库宕机后，假如 relay-log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay-log，并且重新从 master 上获取日志，这样就保证了relay-log 的完整性。
默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时， 可在 slave 从库上开启该功能，建议开启。
 
 
systemctl restart mysqld
 
mysql -u root -p123456
 
CHANGE master to master_host='192.168.209.60',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=604;
#配置同步，注意 master_log_file 和 master_log_pos 的值要与Master查询的一致
 
start slave;                       
#启动同步，如有报错执行 reset slave;
show slave status\G                    
#查看 Slave 状态
//确保 IO 和 SQL 线程都是 Yes，代表同步正常。
Slave_IO_Running: Yes                
#负责与主机的io通信
Slave_SQL_Running: Yes               
 #负责自己的slave mysql进程

重启服务 

进入mysql配置 同步

启动服务 

查看slave状态，看到两个yes 

#一般 Slave_IO_Running: No 的可能性：
1、网络不通
2、my.cnf配置有问题
3、密码、file文件名、pos偏移量不对
4、防火墙没有关闭 

 验证

在主服务器上创建数据库school 

从服务器上查看 

如数据中途加入主从复制的库 需要导出主服务器库 的库文件并且导入到从服务器中 

9.总结

主从复制核心部分 两个日志 三个线程
mysql主从复制原理就是通过主数据库变化记录到二进制日志(bin1og)中，然后从库读取主二进制日志来去存放到本地最后 sql 线程 把数据导入到自己二进制(类似)中保持主从数据一致 

MySQL 主从复制的几个同步模式 

（1）异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

（2）全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

（3）半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

二.读写分离 

1.什么是读写分离

读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

2.读写分离的原因 

因为数据库的“写”操作是比较耗时的，但是数据库的“读”操作相对较快，所以读写分离，解决的是，数据库的写入，影响了查询的效率。

3.进行读写分离的情况

数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用。利用数据库主从同步，再通过读写分离可以分担数据库压力，提高性能。

4.主从复制与读写分离的联系 

在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。有点类似于rsync，但是不同的是rsync是对磁盘文件做备份，而mysql主从复制是对数据库中的数据、语句做备份。

5.目前较为常见的 MySQL 读写分离分为以下两种： 

基于程序代码内部实现

• 在代码中根据 select、insert 进行路由分类，这类方法也是目前生产环境应用最广泛的。

• 优点：性能较好，因为在程序代码中实现，不需要增加额外的设备为硬件开支
• 缺点：需要开发人员来实现，运维人员无从下手。
• 注意：但是并不是所有的应用都适合在程序代码中实现读写分离，像一些大型复杂的Java应用，如果在程序代码中实现读写分离对代码改动就较大。

基于中间代理层实现 

代理一般位于客户端和服务器之间，代理服务器接到客户端请求后通过判断后转发到后端数据库，有以下代表性程序。

（1）MySQL-Proxy。MySQL-Proxy 为 MySQL 开源项目，通过其自带的 lua 脚本进行SQL 判断。

（2）Atlas。是由奇虎360的Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。支持事物以及存储过程。

（3）Amoeba。由陈思儒开发，作者曾就职于阿里巴巴。该程序由Java语言进行开发，阿里巴巴将其用于生产环境。但是它不支持事务和存储过程。

6.基于中间件Amoeba搭建MySQL读写分离 

由于使用MySQL Proxy 需要写大量的Lua脚本，这些Lua并不是现成的，而是需要自己去写。这对于并不熟悉MySQL Proxy 内置变量和MySQL Protocol 的人来说是非常困难的。
Amoeba是一个非常容易使用、可移植性非常强的软件。因此它在生产环境中被广泛应用于数据库的代理层。

 读写分离是基于主从复制的基础上

 7.搭建读写分录

环境准备

Master 主服务器：192.168.209.60

Slave 1 从服务器1:192.168.209.61

Slave 2 从服务器2:192.168.209.63

Amoeba 服务器：192.168.209.64

客户端：192.168.209.62

安装Java环境 

因为 Amoeba 基于是 jdk1.5 开发的，所以官方推荐使用 jdk1.5 或 1.6 版本，高版本不建议使用。
cd /opt/
cp jdk-6u14-linux-x64.bin /usr/local/
cd /usr/local/
chmod +x jdk-6u14-linux-x64.bin
./jdk-6u14-linux-x64.bin
//按yes，按enter
 
mv jdk1.6.0_14/ /usr/local/jdk1.6
 
vim /etc/profile
export JAVA_HOME=/usr/local/jdk1.6
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/lib:$JAVA_HOME/jre/bin/:$PATH:$HOME/bin
export AMOEBA_HOME=/usr/local/amoeba
export PATH=$PATH:$AMOEBA_HOME/bin
 
source /etc/profile
#刷新配置文件
java -version
#查看

将环境包复制到指定地方，然后赋予执行权限 

按enter 

 

刷新后查看 

安装Amoeba软件 

#创建amoeba 的解压目录
[root@amoba opt]#mkdir /usr/local/amoeba
 
[root@amoba opt]#tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
 
#增加目录权限
[root@amoba opt]#chmod -R 755 /usr/local/amoeba/
#开启amoeba
[root@amoba opt]#/usr/local/amoeba/bin/amoeba

//如显示amoeba start|stop说明安装成功

创建文件夹，并解压 

赋权执行 

 

出现 amoeba start|stop表示成功

配置 amoeba 读写分离

主服务器授权：

grant all on *.* to test@'192.168.209.%' identified by '123456';

从服务器授权 

grant all on *.* to test@'192.168.209.%' identified by '123456';

 

amomeba 主机amoeba.xml 配置文件的修改： 

cd /usr/local/amoeba/conf/

备份

修改amoeba配置文件 

vim amoeba.xml
 
--30行--
<property name="user">amoeba</property>
--32行-- 
<property name="password">123</property>
--115行--
<property name="defaultPool">master</property>
--117-去掉注释-
<property name="writePool">master</property>
<property name="readPool">slaves</property>

 30

32 

115

117 

再做另一个备份 

  Aomeba 主机 dbServers.xml 配置文件的设置：

vim dbServers.xml
 
--23行--注释掉  作用：默认进入test库 以防mysql中没有test库时，会报错
<!-- <property name="schema">test</property> -->
--26--修改
<property name="user">test</property>
--28-30--去掉注释
<property name="password">123</property>
--45--修改，设置主服务器的名Master
<dbServer name="master"  parent="abstractServer">
--48--修改，设置主服务器的地址
<property name="ipAddress">192.168.44.60</property>
--52--修改，设置从服务器的名slave1
<dbServer name="slave1"  parent="abstractServer">
--55--修改，设置从服务器1的地址
<property name="ipAddress">192.168.44.50</property>
--58--复制上面6行粘贴，设置从服务器2的名slave2和地址
<dbServer name="slave2"  parent="abstractServer">
<property name="ipAddress">192.168.44.40</property>
--65行--修改
<dbServer name="slaves" virtual="true">
--71行--修改
<property name="poolNames">slave1,slave2</property>

23 

26 

28-30 

 45-48

52-55 

58 

65-71 

 启动

/usr/local/amoeba/bin/amoeba start &					
#后台启动Amoeba软件，按ctrl+c 返回

查看端口

netstat -anpt | grep java
 
或者
lsof -i:8066

客户端测试 

[root@client ~]# yum install -y mariadb-server mariadb
[root@client ~]# systemctl start mariadb.service
[root@client ~]# mysql -u amoeba -p123456 -h 192.168.209.62 -P8066
##通过amoeba服务器代理访问mysql，在通过客户端连接mysql后写入的数据只有主服务会记录，然后同步给从服务器。
##这里通过192.168.209.62主机的8066端口使用用户amoeba登录mysql。

安装mariadb 

 启动

连接数据库

主服务器：

先在主从之间是开启主从同步的，从里面也创建了class表

然后，我们停掉两台从服务器

然后在主服务器里面插入数据

mysql> insert into class values(1,'master','run');

 插入数据

 

客户端查询

开启主从复制 

 三.总结

① 主从同步复制原理

主从复制基于主mysql服务器和从mysql服务器的三个线程和两个日志展开进行的：

两个日志：二进制日志（bin log） 、中继日志（Relay log）

三个线程：dump线程、I/O线程、SQL线程

工作过程：
（1）Master 节点将数据的改变记录成二进制日志（bin log），当Master上的数据发生改变时，则将其改变写入二进制日志中。
（2）Slave节点会在一定时间间隔内对 Master 的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求 Master的二进制事件。
（3）同时 Master 节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至Slave节点本地的中继日志（Relay log）中，Slave节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，即解析成 sql 语句逐一执行，使得其数据和 Master节点的保持一致，最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒。

② 读写分离使用什么方式

通过amoeba代理服务器，实现只在主服务器上写，只在从服务器上读；
主数据库处理事务性查询，从数据库处理select 查询；
数据库复制被用来把事务查询导致的变更同步的集群中的从数据库

③ 如何查看主从同步状态是否成功 

 在从服务器上内输入 show slave status\G 查看主从信息查看里面有IO线程的状态信息，还有master服务器的IP地址、端口事务开始号。
当 Slave_IO_Running和Slave_SQL_Running都是YES时 ，表示主从同步状态成功 

④ 如果I/O不是yes，如何排查 

首先排查网络问题，使用ping 命令查看从服务器是否能与主服务器通信
再查看防火墙和核心防护是否关闭（增强功能）
接着查看从服务slave是否开启
两个从服务器的server-id 是否相同导致只能连接一台
master_log_file master_log_pos的值跟master值是否一致

⑤ show slave status 可以看到哪些信息

IO线程的状态信息
master服务器的IP地址、端口、事务开始的位置
最近一次的错误信息和错误位置
最近一次的I/O报错信息和ID
最近一次的SQL报错信息和id

⑥ 主从复制慢（延迟）会有哪些可能？怎么解决？

• 主服务器的负载过大，被多个睡眠或 僵尸线程占用，导致系统负载过大，从库硬件比主库差，导致复制延迟
• 主从复制单线程，如果主库写作并发太大，来不及传送到从库，就会到导致延迟
• 慢sql语句过多
• 网络延迟

怎么解决：

（1）硬件方面
从库配置更好的硬件，提升随机写的性能。比如原本是机械盘，可以考虑更换为ssd固态。升级核心数更强的cpu、加大内存。避免使用虚拟云主机，使用物理主机

（2）网络方面 
  将从库分布在相同局域网内或网络延迟较小的环境中。尽量避免跨机房，跨网域进行主从数据库服务器的设置

（3）架构方面
在事务当中尽量对主库读写，其他非事务中的读在从库。消除一部分延迟带来的数据库不一致。增加缓存降低一些从库的负载。 

（4）mysqld服务配置方面 
该配置设置针对mysql主从复制性能优化最大化，安全性并不高。如果从安全的角度上考虑的话，就要设置双一设置

追求安全性的双一设置：

innodb_flush_log_at_trx_commit=1
sync_binlog=1

追求性能化设置：

sync_binlog=0
innodb_flush_log_at_trx_commit=2
logs-slave-updates=0
增大 innodb_buffer_pool_size