MySQL半同步复制及搭建
1、半同步复制介绍
异步复制的问题
普通的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,那么将自动降级为普通的复制,直到异常修复。
MySQL 5.5和5.6的半同步复制带来的新问题
如果异常发生,会降级为普通的复制。 那么从机出现数据不一致的几率会减少,并不是完全消失。
主机dumper线程承担的工作变多了,这样显然会降低整个数据库的性能。
在MySQL 5.5和5.6使用after_commit的半同步复制模式下, 即如果slave 没有收到事务,也就是还没有写入到relay log 之前,网络出现异常或者不稳定,此时刚好master挂了,系统切换到从机,两边的数据就会出现不一致。 在此情况下,slave会少一个事务的数据。
MySQL 5.7半同步复制
随着MySQL 5.7版本的发布,半同步复制技术升级为全新的Loss-less Semi-Synchronous Replication架构,其成熟度、数据一致性与执行效率得到显著的提升。
新版本的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结果反馈给客户端。
- 如图1所示。
图1
-
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所示。
图2
2、MySQL5.7 半同步复制搭建(AFTER_SYNC)
搭建环境
master:4核 2G内存 CentOS 6.5 IP:192.168.86.152 主机名:centos65-h1 安装MySQL 5.7.19
slave1:4核 2G内存 CentOS 6.5 IP:192.168.86.153 主机名:centos65-h2 安装MySQL 5.7.19
slave2:4核
2G内存 CentOS 6.5 IP:192.168.86.154 主机名:centos65-h3 安装MySQL 5.7.19