企业级mysql数据库集群----mysql 5.7的半同步复制

一、复制架构衍生史

在谈半同步特性之前，我们先来看看MySQL的复制架构衍生史。
（1）在2000年，MySQL 3.23.15版本引入了Replication。Replication作为一种准实时同步方式，得到广泛应用。这个时候的Replicaton的实现涉及到两个线程，一个在Master，一个在Slave。Slave的I/O和SQL功能是作为一个线程，从Master获取到event后直接apply，没有relay log。这种方式使得读取event的速度会被Slave replay速度拖慢，当主备存在较大延迟时候，会导致大量binary log没有备份到Slave端。
（2）在2002年，MySQL 4.0.2版本将Slave端event读取和执行独立成两个线程（IO线程和SQL线程），同时引入了relay log。IO线程读取event后写入relay log，SQL线程从relay log中读取event然后执行。这样即使SQL线程执行慢，Master的binary log也会尽可能的同步到Slave。当Master宕机，切换到Slave，不会出现大量数据丢失。
（3）在2010年MySQL 5.5版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。于是在MySQL在5.5中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中
那么半同步复制是否可以做到不丢失数据呢？下面分析。
（4）在2016年，MySQL在5.7.17中引入了一个全新的技术，称之为InnoDB Group Replication。目前官方MySQL 5.7.17基于Group replication的全同步技术已经问世，全同步技术带来了更多的数据一致性保障。相信是未来同步技术一个重要方向，值得期待。MySQL 5.7 Group Replication
根据上面提到的这几种复制协议，分别对应MySQL几种复制类型，分别是异步、半同步、全同步。

对于异步复制，主库将事务Binlog事件写入到Binlog文件中，此时主库只会通知一下Dump线程发送这些新的Binlog，然后主库就会继续处理提交操作，而此时不会保证这些Binlog传到任何一个从库节点上。
对于全同步复制，当主库提交事务之后，所有的从库节点必须收到，APPLY并且提交这些事务，然后主库线程才能继续做后续操作。这里面有一个很明显的缺点就是，主库完成一个事务的时间被拉长，性能降低。
对于半同步复制，是介于全同步复制和异步复制之间的一种，主库只需要等待至少一个从库节点收到并且Flush Binlog到Relay Log文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全执行并且提交的反馈，这样就节省了很多时间。

MySQL异步、同步、半同步复制三者的区别

异步复制
MySQL复制默认是异步复制，Master将事件写入binlog，提交事务，自身并不知道slave是否接收是否处理；
缺点：不能保证所有事务都被所有slave接收。
同步复制
Master提交事务，直到事务在所有slave都已提交，才会返回客户端事务执行完毕信息；
缺点：完成一个事务可能造成延迟。
半同步复制
当Master上开启半同步复制功能时，至少有一个slave开启其功能。当Master向slave提交事务，且事务已写入relay-log中并刷新到磁盘上，slave才会告知Master已收到；若Master提交事务受到阻塞，出现等待超时，在一定时间内Master 没被告知已收到，此时Master自动转换为异步复制机制；

注：半同步复制功能要在Master和slave上开启才会起作用，只开启一边，依然是异步复制。

二、半同步复制

我们今天谈论第二种架构。我们知道，普通的replication，即MySQL的异步复制，依靠MySQL二进制日志也即binary log进行数据复制。比如两台机器，一台主机（master），另外一台是从机（slave）。

1）正常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。

2）异常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。

3）很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制。

半同步复制具体特性：

从库会在连接到主库时告诉主库，它是不是配置了半同步。
如果半同步复制在主库端是开启了的，并且至少有一个半同步复制的从库节点，那么此时主库的事务线程在提交时会被阻塞并等待，结果有两种可能，要么至少一个从库节点通知它已经收到了所有这个事务的Binlog事件，要么一直等待直到超过配置的某一个时间点为止，而此时，半同步复制将自动关闭，转换为异步复制。
从库节点只有在接收到某一个事务的所有Binlog，将其写入并Flush到Relay Log文件之后，才会通知对应主库上面的等待线程。
如果在等待过程中，等待时间已经超过了配置的超时时间，没有任何一个从节点通知当前事务，那么此时主库会自动转换为异步复制，当至少一个半同步从节点赶上来时，主库便会自动转换为半同步方式的复制。
半同步复制必须是在主库和从库两端都开启时才行，如果在主库上没打开，或者在主库上开启了而在从库上没有开启，主库都会使用异步方式复制。

如果主库永远启动不了，那么实际上在主库已经成功提交的事务，在从库上是找不到的，也就是数据丢失了，这是MySQL不愿意看到的。所以在MySQL 5.7版本中增加了after_sync（无损复制）参数，并将其设置为默认半同步方式，解决了数据丢失的问题。

三、mysql半同步复制配置

做半同步复制的时候，我们需要在官网上看官方文档，然后根据自己所配置环境的不同来修改，以防自己敲错，在官网上可以粘贴，我们可以看到官方文档中，数据库的输入的命令都为大写，这也是规范写法。
在此点击切换到官网

在做此实验时，我们只需要两台虚拟机，一台主库(server1)，一台备库(server2)，而主库和备库之间已经是异步复制的环境
点击此处搭建异步复制环境

步骤一：在主库(server1)上安装插件

INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;

查看插件是否安装

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE ‘%semi%’;

激活插件

SET GLOBAL rpl_semi_sync_master_enabled =1;

步骤二：在备库(server2)上安装插件

INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;

激活插件

SET GLOBAL rpl_semi_sync_slave_enabled =1;

重启IO线程使半同步生效

mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

在备库上查看半同步状态，是否成功开启
show variables like ‘%rpl%’; 为ON才是开启成功

步骤三：在主库上查看半同步状态是否开启
show status like ‘%rpl%’; 为ON才是开启成功（我们这时候先不要插入数据）
show variables like ‘%rpl%’;

查看主库的变量的值，可以查看到延迟时间(10000指10000毫秒，也就是10秒)

步骤四：停止slave(备库)节点的io线程
步骤五：在主库上插入数据，我们会发现当我们插入数据的时候，会等待10s，
默认延迟是10s，10s后如果没有收到slave节点的返回，就会切换到异步复制。查看半同步状态也是off
再次插入数据，不会等待，因为已经是异步复制



步骤五：开启slave节点上的io线程
查看数据库，查看到了主库插入的数据已经复制过来

步骤六：在备库上查看进程
show processlist;输出结果显示了有哪些线程在运行

每列的含义为：

id列	一个标识
user列	显示当前用户，如果不是root，这个命令就只显示你权限范围内的sql语句
host列	显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户
db列	显示这个进程目前连接的是哪个数据库
command列	显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）
time列	此这个状态持续的时间，单位是秒
state列	显示使用当前连接的sql语句的状态

总结：关闭server2上面的slave，然后在server1上面插入数据
sever1（master）等待10s发现server2（slave）没有发送ACK消息，自动变为异步同步，
然后在server2上把slave上面开启，会把之前的数据读过来
将插件安装在数据库中是临时的，退出重新登陆会失效，永久的可以将配置写在配置文件中