MySQL主从复制（异步复制与半同步复制）

目录

MySQL主从复制

主从复制时的日志格式：

复制架构：

1、一主多从架构

2、多级复制架构

3、双主复制/Dual Master架构

复制方式

一、异步复制

二、半同步复制

---

MySQL主从复制

原理：将主服务器的binlog日志复制到从服务器上执行一遍，达到主从数据的一致状态。

过程：从库开启一个I/O线程，向主库请求Binlog日志。主节点开启一个binlog dump线程，检查自己的二进制日志，并发送给从节点；从库将接收到的数据保存到中继日志（Relay log）中，另外开启一个SQL线程，把Relay中的操作在自身机器上执行一遍

优点：

1. 作为备用数据库，并且不影响业务
2. 可做读写分离，一般是一个写库，一个或多个读库，分布在不同的服务器上，充分发挥服务器和数据库的性能，但要保证数据的一致性

扩展：

1. SQL线程执行完Relay log中的事件后，会将当前的中继日志Relay log删除，避免它占用更多的磁盘空间
2. 为保证从库重启后，仍然知道从哪里开始复制，从库默认会创建两个文件master.info和relay-log.info，分别记录了从库的IO线程当前读取主库binlog的进度和SQL线程应用Relay-log的进度。可通过show slave status \G命令查看从库当前复制的状态

主从复制时的日志格式：

这里的日志格式就是指二进制日志的三种格式：基于语句statement的复制、基于行row的复制、基于语句和行（mix）的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题

show variables like ‘%binlog%format%’;    #查看当前使用的binlog的格式

set binlog_format = ‘row’;                #设置格式，这种方法只在当前session生效

set global binlog_format = ‘row’;       #在全局下设置binlog格式，会影响所有的Session

复制架构：

1、一主多从架构

在主库的请求压力非常大时，可通过配置一主多从复制架构实现读写分离，把大量对实时性要求不是很高的请求通过负载均衡分发到多个从库上去读取数据，降低主库的读取压力。而且在主库出现宕机时，可将一个从库切换为主库继续提供服务

2、多级复制架构

因为每个从库在主库上都会有一个独立的Binlog Dump线程来推送binlog日志，所以随着从库数量的增加，主库的IO压力和网络压力也会随之增加，这时，多级复制架构应运而生。

多级复制架构只是在一主多从的基础上，再主库和各个从库之间增加了一个二级主库Master2，这个二级主库仅仅用来将一级主库推送给它的BInlog日志再推送给各个从库，以此来减轻一级主库的推送压力。

但它的缺点就是Binlog日志要经过两次复制才能到达从库，增加了复制的延时。

我们可以通过在二级从库上应用Blackhol存储引擎（黑洞引擎）来解决这一问题，降低多级复制的延时。

“黑洞引擎”就是写入Blackhole表中数据并不会写到磁盘上，所以这个Blackhole表永远是个空表，对数据的插入/更新/删除操作仅在Binlog中记录，并复制到从库中去。

3、双主复制/Dual Master架构

双主复制架构适用于需要进行主从切换的场景

在只有一个主库的架构下，当主库宕机后，将其中一个从库切换为主库继续提供服务。原来的主库就没有数据来源了，那么当这个新的主库