浅析MySQL的WriteSet并行复制

【历史背景】

　　岁月更迭中我已经从事MySQL-DBA这个工作三个年头，见证MySQL从“基本可用”，“边缘系统可以用MySQL”，“哦操！你怎么不用MySQL”;

　　正所谓！“一个数据库的境遇既取决于历史的进程，取决于它的自我奋斗！”，关于“历史的进程”在此不表，关于“自我奋斗”这里也只想谈一下并行复制的几个关键时间结点

　　总的来说MySQL关于并行复制到目前为止经历过三个比较关键的时间结点“库间并发”，“组提交”，“写集合”；真可谓是江山代有人才出，前浪死在沙滩上；总的来说就后面的比前面的不知道高到哪里去了！

【库间并发】

　　库间并发的理论依据是这样的 ---- 一个实例内可能会有多个库(schema)，不同的库之间没有什么依赖关系，所以在slave那边为每一个库(schema)单独起一个SQL线程，这样就能通过多线程并行复制的方式来提高主从复制的效率。

　　这个理论听起来没问题，但是事实上一个实例也就一个业务库，所以这种库间并发就没什么作用了；也就是说这个方式的适用场景比较少，针对这个不足直到“组提交”才解决！

【组提交】

　　组提交的理论依据是这样的 --- 如果多个事务他们能在同一时间内提交，这个就间接说明了这个几个事务锁上是没有冲突的，也是就说他们各自持有不同的锁，互不影响；逻辑上我们几个事务看一个组，在slave以“组”为单位分配给SQL线程执行，这样多个SQL线程就可以并行跑了；而且不在以库为并行的粒度，效果上要比“库间并发”要好一些。

　　这个事实上也有一些问题，因为它要求库上要有一定的并发度，不然就有可能变成每个组里面只有一个事务，这样就有串行没什么区别了，为了解决这个问题MySQL提供了两个参数就是希望在提交时先等一等，尽可能的让组内多一些事务，以提高并行复制的效率。

　　“binlog_group_commit_sync_no_delay_count” 设置一个下水位，也就是说一个组要凑足多少个事务再提交；为子防止永远也凑不足

　　那么多个事务MySQL还以时间为维度给出了另一个参数“binlog_group_commit_sync_delay”这个参数就是最多等多久，超过这个时间长度后就算没有凑足也提交。　

　　亲身经历呀！ 这两个参数特别难找到合的值，就算今天合适，过几天业务上有点变化后，又可能变的不合适了；如果MySQL能自己达到一个自适应的效果就好了；这个自适用要到WriteSet才完成(WriteSet并不是通过自动调整这两个参数来完成，它采用了完全不同的解决思路)。

【WriteSet】

　　WriteSet解决了什么问题？当然是解决了“组提交”的问题啦！ 说了和没说一个样，好下面我们来举个例子(比较学院派)；假设你第一天更新了id == 1 的那一行，第二天你更新了id == 2 的那一行，第三天有个slave过来同步你的数据啦！ 以“组提交”的尿性，这两个更新会被打包到不同的“组”，也就是说会有两个组；由于每个组内只有一个事务，所以逻辑上就串行了，起来！

　　身为DBA的你一可以看出来这两个事实上是可以打包到同一个组里来的，因为他们互不冲突，就算打包到同一个组也不引起数据的不一致。 于是你有两个办法

　　办法1): 妹妹你大胆的把“binlog_group_commit_sync_no_delay_count”设置成 2,也就是说一个组至少要包含两个事务，并且把“binlog_group_commit_sync_delay”设置成24小时以上！如果你真的做了，你就可以回家了，你的数据库太慢了(第一条update等了一天)，才完成！

　　办法2): 叫MySQL用一本小本子记下它最近改了什么，如果现在要改的数据和之前的数据不冲突，那么他们就可以把包到同一个组；还是我们刚才的例子，由于第二天改的值的id==2所以它和第一天的不冲突，那么它完全可以把第二天的更新和第一天的更新打包到同一个组。这样组里面就有两个事务了，在slave第三天回放时就会有一种并行的效果。

　　这本小本子这么牛逼可以做大一点吗？当然！binlog_transaction_dependency_history_size 这个参数就小本子的容量了；那我的MySQL有这本小本子吗？ 如果你的mysql比mysql-5.7.22新的话，小本子就是它生来就有的。

　　也就是说“WriteSet”是站在“组提交”这个巨人的基础之间建立起来的，而且是在master上做的自“适应”打包分组，所以你只要在master上新增两个参数

binlog_transaction_dependency_tracking = WRITESET         #  COMMIT_ORDER
transaction_write_set_extraction    = XXHASH64

理论说完了，下面我们看一下实践。

【WriteSet实践】

　　基于WriteSet的并行复制环境怎么搭建我这里就不说了，也就是比正常的“组提交”在master上多加两个参数，不讲了；我这里想直接给出两种并行复制方式下的行为变化。

　　1): 我们要执行的目标SQL如下

create database tempdb;
use tempdb;
create table person(id int not null auto_increment primary key,name int);

insert into person(name) values(1);
insert into person(name) values(2);
insert into person(name) values(3);
insert into person(name) values(5);

　　2): 看一下组提交对上面SQL的分组情况

　　3): 看write_set的对“组提交”优化后的情况

　　可以看到各个insert是可以并行执行的，所以它们被分到了同个组(last_committed相同）；last_committed，sequence_number，这两个值在binlog里面记着就有，我在解析binlog的时候习惯使用如下选项

mysqlbinlog -vvv --base64-output='decode-rows' mysql-bin.000002　　

 【总结】

　　WriteSet是在“组提交”方式上建立起来的，一种新的并行复制实现；相比“组提交”来说更加灵活；当然，由于并发度上去了，相比“组提交”WriteSet在性能上会更加好一些，在一些WriteSet没有办法是否冲突时，能平滑过度到“组提交”模式。

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

赞 (0)

相关推荐

  • MySQL主从复制原理以及需要注意的地方

    写在前面 最近在写Mycat专题,由于不少小伙伴最近要出去面试,问我能不能简单写下MySQL的主从复制原理和注意事项,因为在之前的面试中被问到了这些问题.我:可以啊,安排上了!! 主从复制原理 (1) Master 将数据改变记录到二进制日志(binary log)中,也就是配置文件 log-bin 指定的文件, 这些记录叫做二进制日志事件(binary log events): (2) Slave 通过 I/O 线程读取 Master 中的 binary log events 并写入到它的中继

  • mysql 如何动态修改复制过滤器

    MySQL动态修改复制过滤器 说说今天遇到的问题吧,今天在处理一个业务方的需求,比较变态,我大概描述一下: 1.线上的阿里云rds上面有个游戏的日志库,里面的表都是日表的形式,数据量比较大了,每次备份的时候,都会导致线上的rds报警,报警内容是IO资源占用过多. 2.这个rds上有一个本地的ECS只读从库,这个只读从库会实时同步线上的rds数据库中的数据,这个只读从库供业务方查询使用 3.业务方说这些数据都还有用,只读从库上的数据必须有,线上rds上的数据可以删除,保留两个星期即可. 场景就是这

  • MySQL 主从复制原理与实践详解

    本文实例讲述了MySQL 主从复制原理与实践.分享给大家供大家参考,具体如下: 简介 MySQL 的主从复制又叫 Replication.AB 复制.至少需要两个 MySQL 服务(可以是同一台机器,也可以是不同机器之间进行). 比如A服务器做主服务器,B服务器做从服务器,在A服务器上进行数据的更新,通过 binlog 日志记录同步到B服务器上,并重新执行同步过来的 binlog 数据,从而达到两台服务器数据一致. MySQL 数据库的主从复制方案,与使用 scp/rsync 等命令进行的文件级

  • 深入浅出讲解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多线

  • 关于MySQL主从复制的几种复制方式总结

    异步复制 MySQL的复制默认是异步的,主从复制至少需要两个MYSQL服务,这些MySQL服务可以分布在不同的服务器上,也可以在同一台服务器上. MySQL主从异步复制是最常见的复制场景.数据的完整性依赖于主库BINLOG的不丢失,只要主库的BINLOG不丢失,那么就算主库宕机了,我们还可以通过BINLOG把丢失的部分数据通过手工同步到从库上去. 注意:主库宕机的情况下,DBA可以通过mysqlbinlog工具手工访问主库binlog,抽取缺失的日志并同步到从库上去:也可以通过配置高可用MHA架

  • 浅析MySQL并行复制

    01 并行复制的概念 在MySQL的主从复制架构中,主库上经常会并发的执行很多SQL,只要这些SQL没有产生锁等待,那么同一时间并发好几个SQL线程是没有问题的. 我们知道,MySQL的从库是要通过IO_thread去拉取主库上的binlog的,然后存入本地,落盘成relay-log,通过sql_thread来应用这些relay-log. 在MySQL5.6之前的版本中,当主库上有多个线程并发执行SQL时,sql_thread只有一个,在某些TPS比较高的场景下,会出现主库严重延迟的问题.MyS

  • 浅谈MySQL8.0 异步复制的三种方式

    本实验中分别针对空库.脱机.联机三种方式,配置一主两从的mysql标准异步复制.只做整服务器级别的复制,不考虑对个别库表或使用过滤复制的情况. 实验环境 [root@slave2 ~]# cat /etc/hosts 192.168.2.138 master 192.168.2.192 slave1 192.168.2.130 slave2 mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.16 |

  • 浅析MySQL的WriteSet并行复制

    [历史背景] 岁月更迭中我已经从事MySQL-DBA这个工作三个年头,见证MySQL从"基本可用","边缘系统可以用MySQL","哦操!你怎么不用MySQL"; 正所谓!"一个数据库的境遇既取决于历史的进程,取决于它的自我奋斗!",关于"历史的进程"在此不表,关于"自我奋斗"这里也只想谈一下并行复制的几个关键时间结点 总的来说MySQL关于并行复制到目前为止经历过三个比较关键的时间结点

  • MySQL Replication中的并行复制示例详解

    目录 传统单线程复制说明 总结 MySQL5.6基于库级别的并行复制 MySQL5.7基于组提交的并行复制 组提交说明 MySQL8.0基于writeset的并行复制 关键参数查看 参数配置项说明 引用资料: 传统单线程复制说明 众所周知,MySQL在5.6版本之前,主从复制的从节点上有两个线程,分别是I/O线程和SQL线程. I/O线程负责接收二进制日志的Event写入Relay Log. SQL线程读取Relay Log并在数据库中进行回放. 以上方式偶尔会造成延迟,那么可能造成主从节点延迟

  • MySQL5.7并行复制原理及实现

    MySQL5.7并行复制原理及实现

    稍微了解过一点的数据的运维就知道MySQL 5.5以及之前是单SQL线程回放,如果Master QPS稍微高点,从上就有延迟了,5.6是基于库的并行回放机制,只有当多个库的话才有复制才有优势,而5.7是基于组的并行回放,同一组的事务可以并行重放从而解决延迟问题. MySQL 5.7并行复制时代 众所周知,MySQL的复制延迟是一直被诟病的问题之一,然而在Inside君之前的两篇博客中(1,2)中都已经提到了MySQL 5.7版本已经支持"真正"的并行复制功能,官方称为为enhanced

  • MySQL 5.7并发复制隐式bug实例分析

    前言 我们MySQL线上环境大部分使用的是5.7.18的版本,这个版本已修复了很多bug,但针对主从复制的bug还是有很多的,尤其是一些组复制.并行复制的bug尤为突出,在5.7.19版本有做相应改善和修复.所以建议5.7.19之前的版本还是不要使用mgr和并发复制的功能,如使用建议升级至5.7.19(含)以后的版本. 我这里遇到的问题主要是莫名其妙的数据同步出现问题,无法执行stop slave,数据不一致等现象,经过查看发现是版本bug所致,所以对已上线的从库关闭并发复制,对未上线的系统实行

  • 浅析mysql交互式连接&非交互式连接

    浅析mysql交互式连接&非交互式连接

    交互式操作:通俗的说,就是你在你的本机上打开mysql的客户端,就是那个黑窗口,在黑窗口下进行各种sql操作,当然走的肯定是tcp协议. 非交互式操作:就是你在你的项目中进行程序调用.比如一边是tomcat web服务器,一边是数据库服务器,两者怎么通信?在java web里,我们通常会选择hibernate或者是jdbc来连接.那么这时候就是非交互式操作. 在之前,我基本上不关系这两个属性,都是用的是mysql服务商推荐的默认值,就是8小时. 但是,从昨天开始,由于在新网租用了一个空间,而他的

  • 深入浅析MySQL从删库到跑路_高级（一）——数据完整性

    一.数据完整性简介 1.数据完整性简介 数据冗余是指数据库中存在一些重复的数据,数据完整性是指数据库中的数据能够正确反应实际情况. 数据完整性是指数据的可靠性和准确性,数据完整性类型有四种: A.实体完整性:实体的完整性强制表的标识符列或主键的完整性(通过唯一约束,主键约束或标识列属性). B.域完整性:限制类型(数据类型),格式(通过检查约束和规则),可能值范围(通过外键约束,检查约束,默认值定义,非空约束和规则). C.引用完整性:在删除和输入记录时,引用完整性保持表之间已定义的关系.引用完

  • 浅析mysql 定时备份任务

    简介 在生产环境上,为了避免数据的丢失,通常情况下都会定时的对数据库进行备份.而Linux的crontab指令则可以帮助我们实现对数据库定时进行备份.首先我们来简单了解crontab指令,如果你会了请跳到下一个内容mysql备份. 本文章的mysql数据库是安装在docker容器当中,以此为例进行讲解.没有安装到docker容器当中也可以参照参照. contab定时任务 使用crontab -e来编写我们的定时任务. 0 5 * * 1 [command] 前面的5个数字分别代表分.时.日.月.

  • 浅析MySQL 备份与恢复

    1.简介 数据无价,MySQL作为一个数据库系统,其备份自然也是非常重要且有必要去做.备份的理由千千万,预防故障,安全需求,回滚,审计,删了又改的需求等等,备份的重要性不言而喻.除了备份本身, 如何使用备份来恢复 服务也是一项重点内容,不能用来恢复的备份没有意义.本文主要会针对备份和恢复这两方面做一些简单的介绍. 本文为<高性能MySQL>备份相关章节的读书笔记. 2.备份和恢复的简单定义 正如简介所说,备份人尽皆知,也很容易引起人的重视.根据需求写定期脚本,或者使用其他方式都是比较常见的.但

随机推荐