MySQL5.7半同步复制技术

Mysql的复制分为4种：

1、异步复制replication

2、Semi-sync replication  半同步复制 性能基于异步和全同步之间

3、Sync replication 全同步

4、Mysql cluster 基于NDB引擎

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

 

但是会出现问题：

 

当事务t1写入binlog  buffer，dumper线程通知slave有了新的事务t1，binlog buffer进行checkpoint，slave因为网络不稳定，没有收到t1事务，这个时候正好master又挂掉了，slave提升为主库 ，t1事务就丢失了

 

还有一个性能问题：

当主库业务的并发量上来，或者进行大事务的DML操作，slave因为要串行执行master上的并发操作，会导致很大延迟，不过下面的半同步可以解决这个问题

 

半同步基本原理：

在master的dumper线程通知slave后，增加了一个ack（ack作为一个标记），即是否成功收到事务t1的标志码。也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。（这样其实就增加了dumper线程的额外开销）如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复。

 
半同步的问题：
1、如果异常发生，会降级为普通的复制。 那么从机出现数据不一致的几率会减少，并不是完全消失。

2、主机dumper线程承担的工作变多了，这样显然会降低整个数据库的性能。

3、在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 没有收到事务，也就是还没有写入到relay log 之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。 在此情况下，slave会少一个事务的数据。

 

 

什么是after_commit(5.6默认值)和after_sync模式（5.7默认值，5.6没有）?

After_commit

Master将事务写进binlog日志中，传递到slave刷新到relay_log，同时master提交事务。Master等待slave反馈写入了relay log，只有收到sck包后master才会将commit
ok结果反馈给客户端

 

After_sync

master将事务写进binlog中，传到slave刷新到磁盘relay log。Master等待slave收到ack包之后，再提交事务并且返回commit ok结果给客户端，这样即使主库宕机了，也可以保证所有主库上的书屋都已经同步到了slave的relay log上去

 

 

5.7的半同步复制性能也得到大幅度提升，支持发送binlog和接收ack包异步化，似的dumper线程压力减少，不再是同步的瓶颈。

 

rpl_semi_sync_master_wait_slave_count参数，可以控制接收多少个slave写事务成功反馈

 

 

个人认为5.7复制特性里面比较重要的点来了

Replication的组提交

MySQL5.7有个新的变量 slave_parallel_type 他有2个参数

1、database 基于库的并行复制方式

2、Logical——clock 基于组的并行复制方式

 
Mysql5.6也支持并且复制（暂且可以叫他伪并行复制），但是其并行只是基于DATABASE的，也就是基于库的。如果用户的MySQL数据库实例中存在多个DATABASE ，对于从机复制的速度的确可以有比较大的帮助，如果用户实例仅有一个库，那么就无法实现并行回放，甚至性能会比原来的单线程更差。
 
 
MySQL5.7的话会为同时进入commit阶段的事务分配相同的序列号，相同序列号的事务在slave中是可以并发执行的。真正实现了并行复制，最重要的原因是slave的回放和主机是一致的，不会再有库的并行复制限制，对binlog日志的格式也没有特殊的要求。
 
总结：
Mysql5.7在半同步复制技术上使得数据库执行效率得到了质的飞跃。