浅析MySQL并行复制

01 并行复制的概念

在MySQL的主从复制架构中，主库上经常会并发的执行很多SQL，只要这些SQL没有产生锁等待，那么同一时间并发好几个SQL线程是没有问题的。

我们知道，MySQL的从库是要通过IO_thread去拉取主库上的binlog的，然后存入本地，落盘成relay-log，通过sql_thread来应用这些relay-log。

在MySQL5.6之前的版本中，当主库上有多个线程并发执行SQL时，sql_thread只有一个，在某些TPS比较高的场景下，会出现主库严重延迟的问题。MySQL为了解决这个问题，将sql_thread演化了多个worker的形式，在slave端并行应用relay log中的事务，从而提高relay log的应用速度，减少复制延迟。这就是并行复制的由来。

在MySQL中，复制线程是由参数slave_parallel_workers来控制的，通常情况下，在8G内存、8核CPU的机器上，将该值设置为8比较合适，如果你的CPU核数比较高，那么可以适当调整为8~16之间的数字。

mysql> show variables like 'slave_parallel_workers';
+------------------------+-------+
| Variable_name     | Value |
+------------------------+-------+
| slave_parallel_workers | 8   |
+------------------------+-------+
1 row in set, 1 warning (0.00 sec)

02 并行复制的演进

并行复制的本质是同时执行的SQL不存在锁争用。

在MySQL5.6版本，MySQL支持的粒度是按照数据库进行并行执行relay log，这种方式能够解决一部分问题，因为不同数据库上的SQL，肯定不会修改表中的同一行内容。这样也就不会产生锁争用。在一些数据库均匀分布，每个数据库使用频率都差不多的场景下，这种并行复制的方法比较好。如果你的业务的数据都集中在一个热点表，这种情况下，并行复制会退化为单线程复制。

随后，在MariaDB中对并行复制做了一定的改进，它的做法是：

1、主库上能够并行提交的事务，也就是已经进入到了redo log commit阶段的事务，在从库上也一定能够并行提交，所以在主库上并行提交的事务，它用一个commit_id对这组事务来进行标识，下一组并行事务的commit_id为本组的commit_id+1

2、将所有的事务的commit_id写入binlog中

3、在从库上应用binlog的时候，将所有的binlog按照commit_id进行划分到不同的worker上

4、本组commit_id的事务全部在从库上提交完成之后，再去拿下一批事务。

这种方法大大增加了从库应用relay log的速度，但是问题是从库在应用前一组事务的时候，后一组事务是处于等待中的，即使前一组的worker有些已经空闲。而在主库上，可能无时无刻不在写入，这样，系统的吞吐量上主从节点就不匹配，主库的吞吐量严重高于从库。

MySQL5.7的并行复制在MariaDB的基础上做了改进，我们知道，事务进入到redo log prepare阶段的时候，由于WAL技术，说明此时事务已经经过了所冲突检测阶段了。MySQL5.7的并行复制时将所有在主库上处于redo log prepare阶段的事务，和该阶段之后的事务，也就是处于redo log commit阶段的事务，在从库并行执行，从而减少worker线程不必要的等待。

这里，有必要再说两个参数，

  • binnlog_group_commit_sync_delay参数，表示redo log prepare阶段完成之后，延迟多少微秒后才调用fsync;
  • binlog_group_commit_sync_no_delay_count参数，表示累积多少次redo log prepare：write的操作以后才调用fsync

这两个参数是用于故意拉长binlog从write到fsync的时间，以此减少binlog的写盘次数。在MySQL 5.7的并行复制策略里，它们可以用来制造更多的“同时处于prepare阶段的事务”。这样就增加了备库复制的并行度。

它们既可以“故意”让主库提交得慢些，又可以让备库执行得快些。在MySQL 5.7处理备库延迟的时候，可以考虑调整这两个参数值，来达到提升备库复制并发度的目的。

以上就是浅析MySQL并行复制的详细内容，更多关于MySQL并行复制的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • MySQL8.0中的降序索引

    前言 相信大家都知道,索引是有序的:不过,在MySQL之前版本中,只支持升序索引,不支持降序索引,这会带来一些问题:在最新的MySQL 8.0版本中,终于引入了降序索引,接下来我们就来看一看. 降序索引 单列索引 (1)查看测试表结构 mysql> show create table sbtest1\G *************************** 1. row *************************** Table: sbtest1 Create Table: CREAT

  • MySQL CHAR和VARCHAR存储、读取时的差别

    导读 你真的知道CHAR和VARCHAR类型在存储和读取时的区别吗? 还是先抛几条结论吧: 1.存储的时候,CHAR总是会补足空格后再存储,不管用户插入数据时尾部有没有包含空格. 2.存储的时候,VARCHAR不会先补足空格后再存储,但如果是用户在插入时特地加了空格那就会如实存储,而不会给删除. 3.读取数据时,CHAR总是会删除尾部空格(哪怕是写入时包含空格). 4.读取数据时,VARCHAR总是如实取出之前存入的值(如果存储时尾部包含空格,就会继续保留着,不会像CHAR那样删除尾部空格).

  • mysql 主从复制如何跳过报错

    一.传统binlog主从复制,跳过报错方法 mysql> stop slave; mysql> set global sql_slave_skip_counter = 1; mysql> start slave; mysql> show slave status \G 二.GTID主从复制,跳过报错方法 mysql> stop slave: #先关闭slave复制: mysql> change master to ...省略... #配置主从复制: mysql>

  • 浅谈MySQL大表优化方案

    背景 阿里云RDS FOR MySQL(MySQL5.7版本)数据库业务表每月新增数据量超过千万,随着数据量持续增加,我们业务出现大表慢查询,在业务高峰期主业务表的慢查询需要几十秒严重影响业务 方案概述 一.数据库设计及索引优化 MySQL数据库本身高度灵活,造成性能不足,严重依赖开发人员的表设计能力以及索引优化能力,在这里给几点优化建议 时间类型转化为时间戳格式,用int类型储存,建索引增加查询效率 建议字段定义not null,null值很难查询优化且占用额外的索引空间 使用TINYINT类

  • 详解mysql中的存储引擎

    mysql存储引擎概述 什么是存储引擎? MySQL中的数据用各种不同的技术存储在文件(或者内存)中.这些技术中的每一种技术都使用不同的存储机制.索引技巧.锁定水平并且最终提供广泛的不同的功能和能力.通过选择不同的技术,你能够获得额外的速度或者功能,从而改善你的应用的整体功能. 例如,如果你在研究大量的临时数据,你也许需要使用内存存储引擎.内存存储引擎能够在内存中存储所有的表格数据.又或者,你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力). 这些不同的技术以及配套的相关

  • MySQL中json字段的操作方法

    MySQL5.7.8中引入了json字段,这种类型的字段使用的频率比较低,但是在实际操作中,有些业务仍然在用,我们以此为例,介绍下json字段的操作方法: 还是从例子看起: mysql> create table test1(id int,info json); Query OK, 0 rows affected (0.02 sec) mysql> insert into test1 values (1,'{"name":"yeyz","age

  • MySQL学习教程之聚簇索引

    聚簇,其实是相对于InnoDB这个数据库引擎来说的,因此在将聚簇索引的时候,我们通过InnoDB和MyISAM这两个MySQL的数据库引擎展开. InnoDB和MyISAM的数据分布对比 CREATE TABLE test (col1 int NOT NULL, col2 int NOT NULL, PRIMARY KEY(col1), KEY(col2)); 首先通过以上SQL语句创建出一个表格,其中col1是主键,两列数据均创建了索引.然后我们数据的主键取值为1-10000,按照随机的顺序插

  • MySQL删除了记录不生效的原因排查

    线上的一次MySQL事务问题记录 上周五进行了一个大表删除的操作,在删除的过程中,出现了一点小问题,白白花费了两个小时,我这里记录了一下大概的过程,废话不多说了,直接看过程吧. 当时想进行删除,先测试了一下删除语句的语法,删了一条试了一下,如下: mysql ::>>select min(id) from XXXX_user_login; +---------+ | min(id) | +---------+ | | +---------+ row in set (0.00 sec) mysq

  • 记一次MySQL的优化案例

    一  背景 有赞的每个OLTP数据库实例上会设置一个sql-killer进程用于kill 掉执行时间超过一定阈值的sql.下午开发接收到sql被kill的报错,一起帮助开发排查,本文介绍该案例. 二 场景分析 表结构: CREATE TABLE `xxx_info` (   `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',   `user_id` bigint(20) unsigned NOT NULL DEFAULT

  • 深入浅出讲解MySQL的并行复制

    深入浅出讲解MySQL的并行复制

    一.并行复制的背景 首先,为什么会有并行复制这个概念呢? 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多线

随机推荐