MySQL5.7并发复制演进

MySQL5.5及以前的复制

一般主从复制有三个线程且都是单线程:

Binlog Dump(主) --> IO Thread(从) --> SQL Thread(从)。

1、master节点的Binlog dump Thread,当slave节点与master正常连接的时候,master把更新的binlog内容推送到slave节点。

2、slave节点的I/O Thread ,该线程通过读取master节点binlog日志名称以及偏移量信息将其拷贝到本地relay log日志文件。

3、slave节点的SQL Thread,该线程读取relay log日志信息,将在master节点上提交的事务在本地回放,达到与主库数据保持一致的目的。

一般复制出现延迟主要在两个方面:

1)SQL线程忙不过来(可能大事物操作数据量较大;可能和从库本身的一些操作有关,有锁和资源的冲突;主库可以并发写,SQL线程不可以;主要原因)

2)网络抖动导致IO线程复制延迟(次要原因)。

MySQL5.6的改进

MySQL 5.6版本引入并发复制(schema级别),基于schema级别的并发复制核心思想:“不同schema下的表并发提交时的数据不会相互影响,即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程,来重放relay log中主库已经提交的事务,保持数据与主库一致”。可见MySQL5.6版本的并发复制,一个schema分配一个类似SQL线程的功能。

在上图的红色框框部分就是实现并行复制的关键所在。在MySQL 5.6版本之前,Slave服务器上有两个线程I/O线程和SQL线程。I/O线程负责接收二进制日志(更准确的说是二进制日志的event),SQL线程进行回放二进制日志。如果在MySQL 5.6版本开启并行复制功能(slave_parallel_workers > 0),那么SQL线程就变为了coordinator线程,coordinator线程主要负责以下两部分内容:

  • 若判断可以并行执行,那么选择worker线程执行事务的二进制日志。
  • 若判断不可以并行执行,如该操作是DDL,亦或者是事务跨schema操作,则等待所有的worker线程执行完成之后,再执行当前的日志。

这意味着coordinator线程并不是仅将日志发送给worker线程,自己也可以回放日志,但是所有可以并行的操作交付由worker线程完成。

上述机制实现的基于schema的并行复制存在的问题是这样设计的并行复制效果并不高,如果用户实例仅有一个库,那么就无法实现并行回放,甚至性能会比原来的单线程更差,而单库多表是比多库多表更为常见的一种情形。

MySQL5.7的MTS(Enhanced Muti-threadedslaves)

MySQL 5.7引入了新的机制来实现并行复制,不再有基于库的并行复制限制,主要思想就是slave服务器的回放与主机是一致的,即master服务器上是怎么并行执行,slave上就怎样进行并行回放。

为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有:

  • DATABASE:默认值,基于库的并行复制方式(兼容MySQL5.6)
  • LOGICAL_CLOCK:基于组提交的并行复制方式

当slave配置slave_parallel_workers(=8)>0并且global.slave_parallel_type='LOGICAL_CLOCK' 时,可支持一个schema下,slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。但是要实现以上功能,需要在master机器标记binary log中提交的事务哪些事物是可以并发执行,MySQL5.7将组提交的信息存放在GTID中。

那么如果用户没有开启GTID功能,即将参数gtid_mode设置为OFF呢?

故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型,如:

在MySQL 5.7的master机器上,用命令 mysqlbinlog mysql-bin.0000006| grep last_committed 可以看到last_committed和sequence_number,last_committed和sequence_number代表的就是LOGICAL_CLOCK。

server id 15102 end_log_pos14623 CRC32 0x767a33fa GTID last_committed=18 sequence_number=26server id 15102 end_log_pos15199 CRC32 0x7dd1bf05 GTID last_committed=26 sequence_number=27server id 15102 end_log_pos15773 CRC32 0xb01dc76e GTID last_committed=26 sequence_number=28server id 15102 end_log_pos16347 CRC32 0x7a8e0ee8 GTID last_committed=26 sequence_number=29server id 15102 end_log_pos16921 CRC32 0x92516d17 GTID last_committed=26 sequence_number=30server id 15102 end_log_pos17495 CRC32 0xeb14a51e GTID last_committed=26 sequence_number=31server id 15102 end_log_pos18071 CRC32 0x750667d0 GTID last_committed=26 sequence_number=32server id 15102 end_log_pos18645 CRC32 0xcaed6159 GTID last_committed=26 sequence_number=33server id 15102 end_log_pos19219 CRC32 0x62408408 GTID last_committed=26 sequence_number=34server id 15102 end_log_pos19793 CRC32 0x5cf46239 GTID last_committed=33 sequence_number=35

在slave机器的relay log中 last_committed相同的事务(sequence_num不同)可以并发执行。一个组提交的事务(group commit)都是可以并行回放,因为这些事务都已进入到事务的prepare阶段,说明事务之间没有任何冲突(否则就不可能提交)。

从上面截取的信息可以看出last_committed=26的事务一共有8个:从sequence_number=27-34,假设当slave_parallel_workers=8时,Coordinator线程分配这一组事务到worker中排队去执行。

增加master库binary log group commit组中事务的数量可以提高slave机器并发处理事务的数量,MySQL5.7引入 binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count参数来提高binary log组提交并发数量。

MySQL等待binlog_group_commit_sync_delay毫秒的时间直到binlog_group_commit_sync_no_delay_count个事务数时,将进行一次组提交。

MTS配置

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=16

master_info_repository=TABLE (开启MTS功能后,会频繁更新master.info,设置为TABLE减小开销)

relay_log_info_repository=TABLE (开启MTS功能,要求必须置为TABLE)

relay_log_recovery=ON (slave IO线程crash,如果relay-log损坏,则自动放弃所有未执行的relay-log,重新从master上获取日志,保证relay-log的完整性)

slave_preserve_commit_order=1 (保证提交的顺序性)

原文发布于微信公众号 - MYSQL轻松学(learnmysql)

原文发表时间:2017-07-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯云数据库(TencentDB)

腾讯云 CDB : 深入解析 MySQL binlog

本文简要介绍 binlog 原理及其在恢复、复制中的使用方法。

2.6K11
来自专栏Java帮帮-微信公众号-技术文章全总结

在Java程序中处理数据库超时与死锁

简介   每个使用关系型数据库的程序都可能遇到数据死锁或不可用的情况,而这些情况需要在代码中编程来解决;本文主要介绍与数据库事务死锁等情况相关的重试逻辑概念,此...

3185
来自专栏鬼谷君

mysql 5.7主从安装和配置

1574
来自专栏腾讯数据库技术

MySQL Binlog实用攻略

本文简要介绍 binlog 原理及其在恢复、复制中的使用方法,更多深入分析可参考 mysql 官方文档。

8.5K2
来自专栏乐沙弥的世界

ASM 磁盘、目录的管理

ASM磁盘是ASM体系结构的重要组成部分,ASM磁盘由ASM实例来定位、管理,本文主要讲述ASM磁盘组、故障组等等。

1174
来自专栏散尽浮华

分布式监控系统Zabbix-3.0.3-完整安装记录(3)-监控nginx,php,memcache,Low-level discovery磁盘IO

前段时间在公司IDC服务器上部署了zabbix3.0.3监控系统,除了自带的内存/带宽/CPU负载等系统资源监控模板以及mysql监控模板外,接下来对诸如ngi...

2076
来自专栏清风

企业Linux运维SHELL编写规范 原

为了方便维护人员维护,需要规定两个正式脚本的发布路径和维护人员的测试路径,不要将脚本放到规定路径以外,例如:

1066
来自专栏黑泽君的专栏

day73_淘淘商城项目_06_solr索引库搭建 + solr搜索功能实现 + 图片显示等问题解决_匠心笔记

  solr是java开发的。   solr的安装文件。   推荐在Linux环境下使用Solr,需要安装环境Linux。   需要安装jdk。参考链接:htt...

1923
来自专栏吴生的专栏

Mysql数据库主从心得整理

管理mysql主从有2年多了,管理过200多组mysql主从,几乎涉及到各个版本的主从,本博文属于总结性的,有一部分是摘自网络,大部分是根据自己管理的心得和经验...

3797
来自专栏乐沙弥的世界

Oracle 闪回区(Oracle Flash recovery area)

    Oracle闪回区已经有了好几载的岁月了,在10g的时候就被推出一直延续到现在。Oracle闪回区是为RMAN准备的,尽管抛开它我们可以同样完成数据库备...

541

扫码关注云+社区