mysql同步完成才返回,关于Mysql5.6半同步主从复制的开启方法

介绍

先了解一下mysql的主从复制是什么回事,我们都知道,mysql主从复制是基于binlog的复制方式,而mysql默认的主从复制方式,其实是异步复制.

主库实际上并不关心从库是否把数据拉完没有,也不关心从库有没有把数据写进硬盘入库,反正数据丢过去,让从库自己慢慢跑,而实际上这也并不影响主库任何使用的情况.

细心的人就会发现,这种情况下,假如主库临时挂了,binlog还没传输完毕,即使是集群也不能保证说这挂了之后的数据一致性,因为你不能排除别人在主库是正常提交的,而从库没有数据的情况.

然后在某个位面的时间上,就有人提出同步复制的概念,意思就是说,只要从库没写入,主库就不返回完成,这个时候即使主库挂了,这也只是一个未完成的事务,从库也不会记录,能保证数据一致性.

看上去,数据一致性是解决了,但是呢,每个事务的延时就增大了,如果是大事务的话,就更惨,这得看网络带宽能不能顶得住,不然延时更低,性能更差.

最后,在mysql5.5之后,半同步就提出来了,意思就是说,每个事务的复制,至少保证一个从库已经收到了binlog,主库才返回事务完成,但不需要理会从库是否写入硬盘.

这样做虽然延时还是有,但是比起完全的同步方式还是好太多,对于数据一致性要求高的情况,牺牲性能来换取一定的价值,是在所难免的.

光看文字难免有些虚,可以看看下面的图片来大致了解一下,

大家留意上面的数字,

第一部,客户端提交sql语句,

第二部,提交给存储引擎解析并处理数据修改,

第三部,事务在主库处理完毕,处于待完成状态,等待最终完成,

第四部,同时提交给各从库,等待完成,

第五部,从库返回状态给主库,标记已完成,半同步只需要一个从库返回就可以，其他会转成异步

第六部,返回客户端,整个事务已完成.

看上去还是比较不错,主从的数据一致性得到很大的提高,但是延时也不含糊,就是牺牲性能来提高一致性的问题了.

不过我还是得负责任的讲句,在极端的情况下,还是可能会丢一些数据的,所以定期做主从数据校验还是有必要的,例如使用PT工具什么的,至于为什么,这个不仿让大家思考一下,而对于大事务来说,半同步也是比较无力的情况,性能损耗较大.

安装使用

下面来看看如何安装使用半同步,大部分mysql本身并没有预装半同步的组件,需要另外安装,但是一般mysql的包里面会自带so文件,所以只要手动加载一下就可以用了.

先检查下有没有装

然后我们开始准备安装的事情:

去看一下相关文件夹:

看到下面两个,就是半同步的组件了,一个是主库组件,一个是从库组件,你可以两个都装上或者只装一个.

下面开始正式安装:

从库当然也要做

安装完了,就开始准备启动了,

主库很简单,只要设置一下半同步启动就可以了.

当然,你也可以写到配置文件,不过写到配置文件要重启才生效,而且还要重新加载组件,所以这就没意思了.

然后到从库,slave要重启动IO线程来生效，否则还是异步的方式复制数据。

同样你也能写到配置文件,我就不多说了,反正这就启动完毕了.

下面来验证一下是否成功,以下是主库的信息,因为从库很多信息是没有的.

解释几个重要的值。

Rpl_semi_sync_master_status:    是否启用了半同步(有时候可能网络超时导致切换成异步)。

Rpl_semi_sync_master_clients:    半同步模式下Slave一共有多少个。

Rpl_semi_sync_master_no_tx:    往slave发送失败的事务数量(最好不要有)。

Rpl_semi_sync_master_yes_tx:    往slave发送成功的事务数量。

看完上面的解析,大概你也知道我这个状态是正常的了.其他延时类别的,大家得看实际情况.

来看看我们能设置些什么关于半同步的参数

也来看看解析:

rpl_semi_sync_master_enabled:    显示是否已开启半同步机制

rpl_semi_sync_master_timeout:Master等待slave响应的时间，单位是毫秒，默认值是10秒，超过这个时间，slave无响应,将自动转换为异步复制,如果探测到从库恢复后,又从新进入半同步状态

rpl_semi_sync_master_trace_level:监控等级，一共4个等级(1,16,32,64)。

* 1：general 等级，如：记录时间函数失效

* 16：detail 等级，记录更加详细的信息* 32：net wait等级，记录包含有关网络等待的更多信息* 64：function等级，记录包含有关function进入和退出的更多信息

rpl_semi_sync_master_wait_no_slave:    是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on ，每一个事务都会等待，如果slave当掉后，当slave追赶上master的日志时，可以自动的切换为半同步方式，如果为off,则slave追赶上后，也不会采用半同步的方式复制了，需要手工配置。

毫无疑问,这些参数都能通过配置文件或直接set来更改,只要你觉得这个适合你的需求,例如一般我们会把响应时间设成1秒.

最后,我们来看看同样的命令在从库会有些什么信息

也正如我刚才说的,很多信息基本上没有,只有最后一行是不一样的,也只是证明从库半同步正常连接中.

再看看这个

主要就最后两行:

rpl_semi_sync_slave_enabled:    是否开启了从库半同步

rpl_semi_sync_slave_trace_level:    监控等级,默认也是32

rpl_stop_slave_timeout:    控制stop slave 的执行时间，在重放一个大的事务的时候,突然执行stop slave ,命令 stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能，可以通过这个参数控制stop slave 的执行时间,一般不需要修改.

问题汇总

5.7.3新加了一个半同步参数，至少有N个slave接收到日志，然后返回ack，这个半同步事务才能提交，默认是1。当这个值设置到和从库数量相等的话，则效果会等同于全同步复制。

5.7新功能，在控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。旧模式是AFTER_COMMIT，新模式是AFTER_SYNC，默认值：AFTER_SYNC 。master 将每个事务写入binlog ,传递到slave，并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master在主库提交事务并且返回结果给会话。 在AFTER_SYNC模式下，所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash，所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库，可以保障最小的数据损失。

而当半同步复制设置N个slave应答，如果当前Slave小于N,取决于rpl_semi_sync_master_wait_no_slave的设置。

超时时间rpl_semi_sync_master_timeout的值，不应该短过应用(例如JDBC)连接池或线程池的超时时间，这样应用可能出现一直等待或者是抛出异常的问题。

本文转自arthur376 51CTO博客，原文链接：http://blog.51cto.com/arthur376/1827808，如需转载请自行联系原作者