MySQL并行复制的深入浅出

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 一、并行复制的背景 首先,为什么会有并行复制这个概念呢?1. DBA都应该知道,MySQL的复制是基于binlog的。 2. MySQL复制包括两部分,IO线程 和 SQL线程。 3. IO线程主要是用于拉取接收Master传递过来的binlog,并将其写入到relay log 4. SQL线程主要负责解析relay log,并应用到slave中 5. 不管怎么说,IO和SQL线程都是单线程的,然后master却是多线程的,所以难免会有延迟,为了解决这个问题,多线程应运而生了。

一、并行复制的背景

  • 首先,为什么会有并行复制这个概念呢?
1. DBA都应该知道,MySQL的复制是基于binlog的。
2. MySQL复制包括两部分,IO线程 和 SQL线程。
3. IO线程主要是用于拉取接收Master传递过来的binlog,并将其写入到relay log
4. SQL线程主要负责解析relay log,并应用到slave中
5. 不管怎么说,IO和SQL线程都是单线程的,然后master却是多线程的,所以难免会有延迟,为了解决这个问题,多线程应运而生了。
6. IO多线程?
    6.1 IO没必要多线程,因为IO线程并不是瓶颈啊
7. SQL多线程?
    7.1 没错,目前最新的5.6,5.7,8.0 都是在SQL线程上实现了多线程,来提升slave的并发度


接下来,我们就来一窥MySQL在并行复制上的努力和成果吧

二、重点

是否能够并行,关键在于多事务之间是否有锁冲突,这是关键。 下面的并行复制原理就是在看如何让避免锁冲突

三、MySQL5.6 基于schema的并行复制

slave-parallel-type=DATABASE(不同库的事务,没有锁冲突)

之前说过,并行复制的目的就是要让slave尽可能的多线程跑起来,当然基于库级别的多线程也是一种方式(不同库的事务,没有锁冲突)

先说说优点: 实现相对来说简单,对用户来说使用起来也简单
再说说缺点: 由于是基于库的,那么并行的粒度非常粗,现在很多公司的架构是一库一实例,针对这样的架构,5.6的并行复制无能为力。当然还有就是主从事务的先后顺序,对于5.6也是个大问题

话不多说,来张图好了

mts_1

四、MySQL5.7 基于group commit的并行复制

slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同],没有锁冲突. 同一组,肯定没有冲突,否则没办法成为同一组)
slave-parallel-type=LOGICAL_CLOCK : Lock-Based模式(即便不是同一组的事务,只要事务之间没有锁冲突[prepare阶段],就可以并发。 不在同一组,只要N个事务prepare阶段可以重叠,说明没有锁冲突)

group commit,之前的文章有详细描述,这里不多解释。MySQL5.7在组提交的时候,还为每一组的事务打上了标记,现在想想就是为了方便进行MTS吧。

我们先看一组binlog


last_committed=0 sequence_number=1
last_committed=1 sequence_number=2
last_committed=2 sequence_number=3
last_committed=3 sequence_number=4
last_committed=4 sequence_number=5
last_committed=4 sequence_number=6
last_committed=4 sequence_number=7
last_committed=6 sequence_number=8
last_committed=6 sequence_number=9
last_committed=9 sequence_number=10



4.1 Commit-Parent-Based模式

mts_2

4.2 Lock-Based模式

mts_3

五、MySQL8.0 基于write-set的并行复制

关于write-set的并行复制,看姜老师的这篇文章基于WRITESET的MySQL并行复制可以快速理解,再详细的自己去看源码即可

我这里简短的对里面的几个重要概论做些解读,这些是我当时理解的时候有偏差的地方

  • 如何启用write-set并行复制
MySQL 5.7.22+ 支持基于write-set的并行复制

# master
loose-binlog_transaction_dependency_tracking = WRITESET
loose-transaction_write_set_extraction = XXHASH64
binlog_transaction_dependency_history_size = 25000 #默认

#slave
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 32

  • 核心原理
# master

master端在记录binlog的last_committed方式变了
基于commit-order的方式中,last_committed表示同一组的事务拥有同一个parent_commit
基于write-set的方式中,last_committed的含义是保证冲突事务(相同记录)不能拥有同样的last_committed值

当事务每次提交时,会计算修改的每个行记录的WriteSet值,然后查找哈希表中是否已经存在有同样的WriteSet

1. 若无,WriteSet插入到哈希表,写入二进制日志的last_committed值保持不变,意味着上一个事务跟当前事务的last_committed相等,那么在slave就可以并行执行

2. 若有,更新哈希表对应的writeset的value为sequence number,并且写入到二进制日志的last_committed值也要更新为sequnce_number。意味着,相同记录(冲突事务)回放,last_committed值必然不同,必须等待之前的一条记录回放完成后才能执行


# slave

slave的逻辑跟以前一样没有变化,last_committed相同的事务可以并行执行
  • 并行复制如何备份
1. slave的顺序如果不一致,如何备份呢?

    1.1 对于non-gtid的gap情况,xtrabackup拷贝的时候应该会通过某种方式记录某一个一致点,否则无法进行change master
    1.2 对于gitd,gtid模式本身的机制就可以解决gap的问题
  • 要不要开启并行复制呢?
1. 基于order-commit的模式,本身并行复制已经很好了,如果并发量非常高,那么order-commit可以有很好的表现,如果并发量低,order-commit体现不了并行的优势。
但是大家想想,并发量低的MySQL,根本也不需要并行复制吧

2. 基于write-set的模式,这是目前并发度最高的并行复制了,基本可以解决大部分场景,如果并发量高,或者新搭建的slave需要快速追主库,这是最好的办法。

3. 单线程复制 + 安全参数双0,这种模式同样拥有不随的表现,一般压力均可应付。

以上三种情况,是目前解决延迟的最普遍的方法,目前我用的最多的是最后一种

  • 后面的事务比前面的事务先执行,有什么影响
1. slave的gtid会产生gap

2. 事务在某个时刻是不一致的,但是最终是一致的, 满足最终一致性

3. 相同记录的修改,会按照顺序执行。不同记录的修改,可以产生并行,并无数据一致性风险

总结,基本没啥影响

六、如何让slave的并行复制和master的事务执行的顺序一致呢

5.7.19 之后,可以通过设置 slave_preserve_commit_order = 1

官方解释:
For multithreaded slaves, enabling this variable ensures that transactions are externalized on the slave in the same order as they appear in the slave's relay log.
Setting this variable has no effect on slaves for which multithreading is not enabled.
All replication threads (for all replication channels if you are using multiple replication channels) must be stopped before changing this variable.
--log-bin and --log-slave-updates must be enabled on the slave.
In addition --slave-parallel-type must be set to LOGICAL_CLOCK.

Once a multithreaded slave has been started, transactions can begin to execute in parallel.
With slave_preserve_commit_order enabled, the executing thread waits until all previous transactions are committed before committing.
While the slave thread is waiting for other workers to commit their transactions it reports its status as Waiting for preceding transaction to commit.

大致实现原理就是:excecution阶段可以并行执行,binlog flush的时候,按顺序进行。 引擎层提交的时候,根据binlog_order_commit也是排队顺序完成
换句话说,如果设置了这个参数,master是怎么并行的,slave就怎么办并行
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
4月前
|
关系型数据库 MySQL 分布式数据库
PolarDB MySQL版并行查询技术探索与实践
PolarDB MySQL版并行查询技术探索与实践 PolarDB MySQL版在企业级查询加速特性上进行了深度技术探索,其中并行查询作为其重要组成部分,已经在线稳定运行多年,持续演进。本文将详细介绍并行查询的背景、挑战、方案、特性以及实践。
107 2
|
5月前
|
SQL 关系型数据库 MySQL
Flink CDC 现在支持mysql 的并行复制吗?
Flink CDC 现在支持mysql 的并行复制吗?
104 1
|
5月前
|
关系型数据库 MySQL
MySQL 5.7 基于GTID主从复制+并行复制+半同步复制
MySQL 5.7 基于GTID主从复制+并行复制+半同步复制
76 0
|
关系型数据库 MySQL
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
534 0
|
存储 SQL Cloud Native
基于 PolarDB for MySQL 实现并行创建索引赛题解析 | 学习笔记
快速学习基于 PolarDB for MySQL 实现并行创建索引赛题解析
174 0
基于 PolarDB for MySQL 实现并行创建索引赛题解析 | 学习笔记
|
存储 Cloud Native 关系型数据库
PolarDB MySQL 弹性多机并行深度剖析
背景并行查询(Parallel Query)是自PolarDB MySQL诞生伊始就致力于研发的企业级查询加速功能,这与PolarDB的产品定位密切相关,基于云原生的计算存储分离使底层数据量远突破单机容量的限制,而针对更海量数据的复杂分析、报表类业务也成为用户自然而然的需求,同时由于PolarDB是服务于在线业务(OLTP)的关系数据库系统,用户会希望分析业务能具有"在线"的能
823 0
PolarDB MySQL 弹性多机并行深度剖析
|
SQL 关系型数据库 MySQL
MySQL 8.0.31并行构建索引特性管窥
测试效率提升36% ~ 100%,相当可观
186 0
MySQL 8.0.31并行构建索引特性管窥
|
SQL 存储 算法
MySQL并行复制
一、MySQL的主从复制 1.1 主从复制基本原理   MySQL的主从架构依赖于MySQL Binlog功能,Master节点上产生Binlog并且写入到文件中。  Master节点上启动一个DUMP线程:当Slave节点I/O线程连接Master时,Master创建这个线程,DUMP线程负责从Master的binlog文件读取记录,然后发送给Slave。
1078 0
|
SQL 分布式计算 并行计算
PostgreSQL 并行计算解说 之10 - parallel 自定义并行函数(UDF)
标签 PostgreSQL , cpu 并行 , smp 并行 , 并行计算 , gpu 并行 , 并行过程支持 背景 PostgreSQL 11 优化器已经支持了非常多场合的并行。简单估计,已支持27余种场景的并行计算。 parallel seq scan parallel index scan
1602 0
|
关系型数据库 PolarDB 分布式数据库
今天你并行了吗?POLARDB for MySQL并行查询加速全程详解
在刚刚结束的乌镇世界互联网大会上,阿里云自研POLARDB云原生数据库当选世界互联网领先科技成果。POLARDB既融合了商业数据库稳定可靠、高性能、可扩展的特征,又具有开源云数据库简单开放、自我迭代的优势。
5181 0