MySQL 5.7 深度剖析: 半同步复制手艺
复制架构衍生史
在谈这个特征之前，我们先来看看MySQL的复制架构衍生史。 MySQL的复制分为四种：
一般的replication，异步同步。 搭建简朴，运用非常普遍，从mysql降生之初，就产生了这类架构，机能非常好，可谓非常成熟。 然则这类架构数据是异步的，所以有丧失数据库的风险。
semi-sync replication，半同步。机能，功用都介于异步和全同步中心。从mysql5.5最先降生，目标是为了折衷上述两种架构的机能以及优缺点。
sync replication，全同步。现在官方5.7基于Group replication的全同步手艺处在labs版本，离正式集成已不远。全同步手艺带来了更多的数据一致性保证。置信是将来同步手艺一个重要方向，值得期待。
mysql cluster。 基于NDB引擎，搭建也简朴，自身也比较稳定，是mysql内里对数据庇护最靠谱的架构，也是现在唯一一个数据完整同步的架构，数据零丧失。不过对营业比较抉剔，限定也较多。
半同步复制
我们本日议论第二种架构。我们晓得，一般的replication，即mysql的异步复制，依托mysql二进制日记也即binary log举行数据复制。比方两台机械，一台主机(master)，别的一台是从机(slave)。
一般的复制为：事件一（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提拔为新的master，t1丧失。
很大的题目是：主机和从机事件更新的差别步，就算是没有收集或许其他体系的非常，当营业并发上来时，slave由于要递次实行master批量事件，致使很大的耽误。
为了填补以上几种场景的不足，mysql从5.5最先推出了半同步。即在master的dumper线程关照slave后，增加了一个ack，即是不是胜利收到t1的标志码。也就是dumper线程除了发送t1到slave，还负担了吸收slave的ack事情。假如涌现非常，没有收到ack，那末将自动降级为一般的复制，直到非常修复。
我们能够看到半同步带来的新题目：
假如非常发作，会降级为一般的复制。 那末从机涌现数据不一致的概率会削减，并非完整消逝。
主机dumper线程负担的事情变多了，如许显然会下降全部数据库的机能。
在MySQL 5.5和5.6运用after_commit的形式下, 即假如slave 没有收到事件，也就是还没有写入到relay log 之前，收集涌现非常或许不稳定，此时恰好master挂了，体系切换到从机，双方的数据就会涌现不一致。 在此情况下，slave会少一个事件的数据。
跟着MySQL 5.7版本的宣布，半同步复制手艺升级为全新的Loss-less Semi-Synchronous Replication架构，其成熟度、数据一致性与实行效力获得明显的提拔。
MySQL 5.7数据复制效力的革新
主从一致性增强, 支撑在事件commit前守候ACK
新版本的semi sync 增加了rpl_semi_sync_master_wait_point参数, 来掌握半同步形式下主库在返回给会话事件胜利之前提交事件的体式格局。
该参数有两个值：
AFTER_COMMIT（5.6默认值）
master将每一个事件写入binlog ,通报到slave 刷新到磁盘(relay log)，同时主库提交事件。master守候slave 反应收到relay log，只要收到ACK后master才将commit OK效果反应给客户端。
AFTER_SYNC（5.7默认值，但5.6中无此形式）
master 将每一个事件写入binlog , 通报到slave 刷新到磁盘(relay log)。master守候slave 反应吸收到relay log的ack以后，再提交事件而且返回commit OK效果给客户端。 纵然主库crash，一切在主库上已提交的事件都能保证已同步到slave的relay log中。
因而5.7引入了after_sync形式，带来的重要收益是处理after_commit致使的master crash主从间数据不一致题目，因而在引入after_sync形式后，一切提交的数据已都被复制，毛病切换时数据一致性将获得提拔。
机能提拔, 支撑发送binlog和接收ack的异步化
旧版本的semi sync 受限于dump thread ，缘由是dump thread 负担了两份差别且又非常频仍的使命：传送binlog 给slave ，还需要守候slave反应信息，而且这两个使命是串行的，dump thread 必需守候 slave 返回以后才会传送下一个 events 事件。dump thread 已然成为全部半同步进步机能的瓶颈。在高并发营业场景下，如许的机制会影响数据库团体的TPS 。
为了处理上述题目，在5.7版本的semi sync 框架中，自力出一个 ack collector thread ，特地用于吸收slave 的反应信息。如许master 上有两个线程自力事情，能够同时发送binlog 到slave ，和吸收slave的反应。
机能提拔, 掌握主库吸收slave 写事件胜利反应数目
MySQL 5.7 新增了rpl_semi_sync_master_wait_slave_count参数，能够用来掌握主库接收多少个slave写事件胜利反应，给高可用架构切换供应了灵活性。
如图所示，当count值为2时，master需守候两个slave的ack。
机能提拔, Binlog 互斥锁革新
旧版本半同步复制在主提交binlog的写会话和dump thread读binlog的操纵都会对binlog增加互斥锁，致使binlog文件的读写是串行化的，存在并发度的题目。
MySQL 5.7 对binlog lock举行了以下两方面优化:
1. 移除了dump thread对binlog的互斥锁
2. 加入了平安边际保证binlog的读平安
机能提拔, 组提交
MySQL 5.7 引入了新的变量slave-parallel-type，其能够设置的值有：
1. DATABASE （5.7之前默认值），基于库的并行复制体式格局；
2. LOGICAL_CLOCK （5.7新增值），基于组提交的并行复制体式格局；
MySQL 5.6版本也支撑所谓的并行复制，然则其并行只是基于DATABASE的，也就是基于库的。假如用户的MySQL数据库实例中存在多个DATABASE ，关于从机复制的速率确实能够有比较大的协助，假如用户实例唯一一个库，那末就没法完成并行回放，以至机能会比本来的单线程更差。
MySQL5.7中增加了一种新的并行形式：为同时进入COMMIT阶段的事件分派雷同的序列号，这些具有雷同序列号的事件在备库是能够并发实行的。
MySQL 5.7真正完成的并行复制，这个中最为重要的缘由就是slave服务器的回放与主机是一致的即master服务器上是如何并行实行的slave上就如何举行并行回放。不再有库的并行复制限定，关于二进制日记花样也无特别的请求（基于库的并行复制也没有请求）。
因而下面的序列中能够并发的序列为（个中前面一个数字为last_committed ，背面一个数字为sequence_number ）：
trx1 1…..2 trx2 1………….3 trx3 1…………………….4 trx4 2……………………….5 trx5 3…………………………..6 trx6 3………………………………7 trx7 6………………………………..8
备库并行划定规矩：当分发一个事件时，其last_committed 序列号比当前正在实行的事件的最小sequence_number要小时，则许可实行。因而:
1. trx1实行，last_commit<2的可并发，trx2, trx3可继承分发实行
2. trx1实行完成后，last_commit < 3的能够实行， trx4可分发
3. trx2实行完成后，last_commit < 4的能够实行， trx5, trx6可分发
4. trx3、trx4、trx5完成后，last_commit < 7的能够实行，trx7可分发
综述
我们以为MySQL 5.7版对半同步复制手艺的优化，使得其成熟度和实行效力都获得了质的进步。我们发起在运用MySQL 5.7作为生产环境的布置时，能够运用半同步手艺作为高可用与读写星散计划的数据复制计划。
以上就是MySQL 5.7 深度剖析: 半同步复制手艺 的细致内容，更多请关注ki4网别的相干文章！
