[MySQL] 号称永久解决了复制延迟问题的并行复制,MySQL5.7-阿里云开发者社区

开发者社区> 数据库> 正文

[MySQL] 号称永久解决了复制延迟问题的并行复制,MySQL5.7

简介: 原文:[MySQL] 号称永久解决了复制延迟问题的并行复制,MySQL5.7 一、缘由:   某天看到主从复制延时的告警有点频繁,就想着是不是彻底可以解决一下。   一般主从复制,有三个线程参与,都是单线程:Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从)。
原文:[MySQL] 号称永久解决了复制延迟问题的并行复制,MySQL5.7

一、缘由:

  某天看到主从复制延时的告警有点频繁,就想着是不是彻底可以解决一下。

  一般主从复制,有三个线程参与,都是单线程:Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从)。复制出现延迟一般出在两个地方

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

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

 

二、解决办法:

  MySQL从5.6开始有了SQL Thread多个的概念,可以并发还原数据,即并行复制技术。

  MySQL 5.6中,设置参数slave_parallel_workers = 4(>1),即可有4个SQL Thread(coordinator线程)来进行并行复制,其状态为:Waiting for an evant from Coordinator。

但是其并行只是基于Schema的,也就是基于库的。如果数据库实例中存在多个Schema,这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形,

那基于库的并发就没有卵用。其核心思想是:不同schema下的表并发提交时的数据不会相互影响,即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程,

来重放relay log中主库已经提交的事务,保持数据与主库一致。

  在MySQL 5.7中,引入了基于组提交的并行复制(Enhanced Multi-threaded Slaves),设置参数slave_parallel_workers>0并且global.slave_parallel_type=‘LOGICAL_CLOCK’,

即可支持一个schema下,slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想:一个组提交的事务都是可以并行回放(配合binary log group commit);

slave机器的relay log last_committed相同的事务(sequence_num不同)可以并发执行。

  其中,变量slave-parallel-type可以有两个值:DATABASE 默认值,基于库的并行复制方式;LOGICAL_CLOCK:基于组提交的并行复制方式

MySQL 5.7开启Enhanced Multi-Threaded Slave配置:

# slave
 slave-parallel-type=LOGICAL_CLOCK
 slave-parallel-workers=16
 master_info_repository=TABLE
 relay_log_info_repository=TABLE
 relay_log_recovery=ON

 

至此,MySQL彻底解决了复制延迟问题,可喜可贺!

 

三、参考文档

  官方文档:https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html

  Inside君的文章:http://www.ttlsa.com/mysql/mysql-5-7-enhanced-multi-thread-salve/

  

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章