mysql半同步怎么判断的简单介绍

怎么判断mysql是否是半同步复制

在谈这个特性之前，我们先来看看mysql的复制架构衍生史。 MySQL的复制分为三种：         第一种，即普通的replication。 搭建简单，使用非常广泛，从mysql诞生之初，就产生了这种架构，性能非常好，可谓非常成熟。 但是这种架构数据是异步的，所以有丢失数据库的风险。         第二种，即mysql cluster。 搭建也简单，本身也比较稳定，是mysql里面对数据保护最最靠谱的架构，也是唯一一个数据完全同步的架构，绝对的零丢失。不过性能就差远些了。        第三种，即semi-sync replication，半同步，性能，功能都介于以上两者之间。从mysql5.5开始诞生，目的是为了折中上述两种架构的性能以及优缺点。“我们今天谈论第三种架构

我们知道，普通的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，那么将自动降级为普通的复制，直到异常修复。

我们可以看到半同步带来的新问题：         1. 如果异常发生，会降级为普通的复制。 那么从机出现数据不一致的几率会减少，并不是完全消失。         2. 主机dumper线程承担的工作变多了，这样显然会降低整个数据库的性能。         3. 在MySQL 5.5和5.6使用after_commit的模式下,  即如果slave 没有收到事务，也就是还没有写入到relay log 之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。 在此情况下，slave会少一个事务的数据。

随着MySQL 5.7版本的发布，半同步复制技术升级为全新的Loss-less Semi-Synchronous Replication架构，其成熟度、数据一致性与执行效率得到显著的提升。

MySQL 5.7对数据复制效率进行了改进1 主从一致性加强支持在事务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模式后，所有提交的数据已经都被复制，故障切换时数据一致性将得到提升。

2 性能提升支持发送binlog和接受ack的异步化

旧版本的semi sync 受限于dump thread ，原因是dump thread 承担了两份不同且又十分频繁的任务：传送binlog 给slave ，还需要等待slave反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS .

图：Without ACK receiving thread

为了解决上述问题，在5.7版本的semi sync 框架中，独立出一个 ack collector thread ，专门用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。

图：With ACK receiving thread3 性能提升控制主库接收slave 写事务成功反馈数量

MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count参数，可以用来控制主库接受多少个slave写事务成功反馈，给高可用架构切换提供了灵活性。

如图所示，当count值为2时，master需等待两个slave的ack

4 性能提升

Binlog 互斥锁改进

旧版本半同步复制在主提交binlog的写会话和dump thread读binlog的操作都会对binlog添加互斥锁，导致binlog文件的读写是串行化的，存在并发度的问题。

MySQL 5.7对binlog lock进行了以下两方面优化

1.移除了dump thread对binlog的互斥锁

2.加入了安全边际保证binlog的读安全

5 性能提升组提交

5.7引入了新的变量slave-parallel-type，其可以配置的值有：

DATABASE （5.7之前默认值），基于库的并行复制方式；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…..2trx2 1………….3trx3 1…………………….4trx4        2……………………….5trx5               3…………………………..6trx6                     3………………………………7trx7                            6………………………………..8

备库并行规则：当分发一个事务时，其last_committed 序列号比当前正在执行的事务的最小sequence_number要小时，则允许执行。

因此，

a)trx1执行，last_commit2的可并发，trx2, trx3可继续分发执行

b)trx1执行完成后，last_commit 3的可以执行， trx4可分发

c)trx2执行完成后，last_commit  4的可以执行， trx5, trx6可分发

d)trx3、trx4、trx5完成后，last_commit 7的可以执行，trx7可分发

综上所述

我们认为MySQL 5.7版对Loss-Less半同步复制技术的优化，使得其成熟度和执行效率都得到了质的提高。我们建议在使用MySQL 5.7作为生产环境的部署时，可以使用半同步技术作为高可用与读写分离方案的数据复制方案。

请点击输入图片描述

mysql 异步复制和半同步复制

在MySQL5.5之前，MySQL 的复制是异步操作，主库和从库的数据之间存在一定的延迟，这样存在一个隐患:当在主库上写入一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库宕机了，例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失，此时从库就可能损失这个事务，从而造成主从不一致。

为了解决这个问题, MySQL5.5引人了半同步复制机制。

在MySQL 5.5之前的异步复制时，主库执行完 Commit提交操作后，在主库写入 Binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库，如图31-7所示。

而半同步复制时，为了保证主库上的每一个 Binlog 事务都能够被可靠的复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待其中一个从库也接收到 Binlog事务并成功写入中继日志后，主库才返回Commit操作成功给客户端。 半同步复制保证了事务成功提交后，至少有两份日志记录 ，一份在主库的 Binlog日志上，另一份在至少一个从库的中继日志Relay Log 上，从而更进一步保证了数据的完整性。半同步复制的大致流程如图31-8所示。

半同步复制模式下，假如在图31-8的步骤1、2、3中的任何一个步骤中主库宕机，则事务并未提交成功，从库上也没有收到事务对应的 Binlog日志，所以主从数据是一致的;

假如在步骤4传送 Binlog日志到从库时，从库宕机或者网络故障，导致 Binlog并没有及时地传送到从库上，此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定)，如果 Binlog 在这段时间内都无法成功推送到从库上，则 MySQL自动调整复制为异步模式，事务正常返回提交结果给客户端。

半同步复制很大程度上取决于主从库之间的网络情况，往返时延RTT 越小决定了从库的实时性越好。通俗地说，主从库之间网络越快，从库越实时。

半同步模式是作为MySQL5.5的一个插件来实现的，主库和从库使用不同的插件。安装比较简单，在上一小节异步复制的环境上，安装半同步复制插件即可。

1、首先,判断MySQL服务器是否支持动态增加插件:

2、安装插件

3、可以查看到已安装的插件

4、在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开启半同步

主：

从：

以上的启动方式是在命令行操作，也可写在配置文件中。

主：

从：

4、重启从上的IO线程

从：

如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色。这时候，主的error.log中会打印如下信息：

查看半同步是否在运行

主：

从：

这两个变量常用来监控主从是否运行在半同步复制模式下。至此，MySQL半同步复制搭建完毕~

来做个实验，观察半同步状态参数的变化。

1、在主库上insert一条记录，观察下变化；

Rpl_semi_sync_master_net_waits加1，说明刚才的insert已经发送到从机并且主机还接收到从机的反馈响应；

2、我们将从机mysql停止，再次在主机上进行insert后查看状态

可以看到，主机进行insert阻塞了10秒才返回结果。Rpl_semi_sync_master_status变为OFF，Rpl_semi_sync_master_no_tx加1，说明这条insert没有同步到从机。后面再一次执行了insert立马返回了结果，说明此时已经降级为异步复制；Rpl_semi_sync_master_no_tx也是增加了1；

3、现在恢复启动从机，再次在主机上进行insert后查看状态

Rpl_semi_sync_master_status还是OFF，Rpl_semi_sync_master_no_tx又增加了1。说明从库重启并不会自动恢复为原来的半同步复制，需要手动操作：

主 SET GLOBAL rpl_semi_sync_master_enabled = 1;

从 SET GLOBAL rpl_semi_sync_slave_enabled = 1; STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

上面是从机重启后的变化，那么主到从之间的网络问题呢，我们可以利用防火墙来模拟。

对于全同步复制，当主库提交事务之后，所有的从库节点必须收到，APPLY并且提交这些事务，然后主库线程才能继续做后续操作。这里面有一个很明显的缺点就是，主库完成一个事务的时间被拉长，性能降低。

mysql的复制 半同步和同步的区别

异步复制（Asynchronous replication）

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

全同步复制（Fully synchronous replication）

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

半同步复制（Semisynchronous replication）

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