资讯专栏INFORMATION COLUMN

MySQL 的 MTS

IT那活儿 / 360人阅读
MySQL 的 MTS
点击上方“IT那活儿”公众号,关注后了解更多内容,不管IT什么活儿,干就完了!!! 

  
Mysql的并行复制技术演变,mysql并行复制enhanced multi-threaded slave, 5.6是基于schema并行,到5.7的group commit在这之前redo log和binlog串行刷盘很影响性能,group commit出现将事务分组,组内的binlog刷盘动作交给一个事务进行,实现组提交目的,通过redo log和binlog的组提交解决磁盘IO的性能。


MTS based on schema

涉及不同 schema 的 DML 操作,在 slave 端可以按 schema 粒度并行回放,弱点也很明显,如果实例中的 schema 较少,并行回放效果并不理想。其优化方式也比较简单 slave_parallel_workers 小于等于 master 的 schema 数量。

LOGICAL_CLOCK并行复制

参数 slave-parallel-type 来控制并行复制策略,配置为 LOGICAL_CLOCK。

原理:redo log组提交(group commit)策略,为同一组一起提交的事务维护一个commit_id,并写入binlog日志。日志传到备库后,coordinator会以轮询的方式将相同commit_id的事务分发到多个worker执行,待一组执行完成后,再取下一批。

在 binlog 中每个事务会有多出两个标签

  • sequence_number:随每个事务递增的自增 ID,每次新的 binlog 会从 1 开始;

  • last_committed:当前事务所依赖的上次事务的 sequence_number,每次新的 binlog 会从 0 开始。

last_committed 相同值的事务代表同时提交的,可以并行回放。
#180105 20:08:33 ... last_committed=7201 sequence_number=7203
#180105 20:08:33 ... last_committed=7203 sequence_number=7204
#180105 20:08:33 ... last_committed=7203 sequence_number=7205
#180105 20:08:33 ... last_committed=7203 sequence_number=7206
#180105 20:08:33 ... last_committed=7205 sequence_number=7207
  • 7203 事务依赖 7201;
  • 7204、7205、7206 事务依赖 7203,可以并行提交;
  • 7207 事务依赖 7205,由于 7205 依赖 7203,那么在 7205 执行完后,7207 可以和 7206 并行执行。
优化方式通过调整 master group commit size 和 slave 的并行 work 线程数,提升并行效率。
master group commit size 和并发压力,master group commit size主要跟下面两个参数相关:
  • binlog_group_commit_sync_delay

    表示 binlog 提交事务前等待多少微秒;

  • binlog_group_commit_sync_no_delay_count

    表示同步队列最大允许的事务数,当等待提交的线程达到多少时, 就不在等待,在 master 低并发的负载下,并行回放效果就不好了,如果想要提高并行度,需要增加 binlog_group_commit_sync_delay,积累较多的分组大小,副作用是拉低 master 吞吐量。

Write set

上述基于组提交的并行存在一些问题,组提交的理论依据是如果多个事务他们能在同一时间内提交,这个就间接说明了这个几个事务锁上是没有冲突的,也是就说他们各自持有不同的锁,互不影响;逻辑上可以把这几个事务看成一个组,在slave以“组”为单位分配给sql线程执行,这样多个sql线程就可以并行跑了。所以它要求库上要有一定的并发度,不然就有可能变成每个组里面只有一个事务,这样就有串行没什么区别了。

writeset就解决了上述的问题,如果两次修改的数据没有冲突,就会打包到一个组里面并行回放,WriteSet通过检测两个事务是否更新了相同的记录来判断事务能否并行回放的,因此需要在运行时保存已经提交的事务信息以记录历史事务更新了哪些行。记录历史事务的参数为binlog_transaction_dependency_history_size。该值越大可以记录更多的已经提交的事务信息,不过需要注意的是,这个值并非指事务大小,而是指追踪的事务更新信息的数量。

开启writeset:

  • binlog_format=row
  • 开启 transaction_write_set_extraction=XXHASH64
  • 更新表必须有主键,如果更新事务包含外键,则退回 commit_order 方式
  • binlog_transaction_dependency_tracking = [COMMIT_ORDER | WRITESET | WRITESET_SESSION]
slave 上开启 slave_parallel_workers。

本文作者:饶茂林(上海新炬王翦团队)

本文来源:“IT那活儿”公众号

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129297.html

相关文章

  • 《30天自制操作系统》第9天

    摘要:内存容量检查要做内存管理,首先得知道内存的容量,怎么知道内存的容量呢可以告诉我们答案。但使用稍微有点麻烦,于是,作者决定自己写程序检查内存容量。状态寄存器的第位位,对齐检查,在中即使将它设置为,它也会变成,而中不会出现这种情况。 第九天 内存管理 1.整理源文件 这一节只是进行了代码整理,把...

    zzzmh 评论0 收藏0
  • 媒体转码截图和工作流场景常见问题【系列一】

    摘要:首先确保输入文件内容正常,其次保证截图配置是否符合规格,可按照本文中常见问题一一对照,特别注意截图时间点,关键帧等信息。媒体工作流执行时,转码管道上绑定的队列或通知机制是否同时生效目前媒体工作流触发执行的作业,忽略转码管道上绑定的消息机制。 摘要: 媒体处理创建消息主题出现Only one topic can be created!错误 目前媒体处理每个用户只能开一个管道,无法创建多管...

    scq000 评论0 收藏0
  • NPM酷库:file-type,检测文件类型

    摘要:通常,我们的程序通过文件后缀名检测类型,这是最直接简洁的方式。原理可以直接检测一个数据流,得到这个数据的内容文件类型。的原理是检测文件数据的。通常情况下,一些知名的文件类型,在其文件开头的几个字节用来标志其文件类型,这几个字节就叫做。 NPM酷库,每天两分钟,了解一个流行NPM库。 通常,我们的程序通过文件后缀名检测类型,这是最直接简洁的方式。但是,在一些情况下,直接通过后缀名检测文件...

    CarterLi 评论0 收藏0
  • 前端容器化——Node.Js & Mongodb

    摘要:另外,中间件还提供了诸如日志记录之类功能,便于查询任务状态以及信息。 DevOps大热,这里我们借着上线一个node中间件,简单介绍下前端容器化相关的内容 原文:http://blog.thonatos.com/dockerizing-your-frontend-project/ (很多东西还来不及写,有时间再补充吧T.T,比如:如何快速在服务器部署vpn神马の一定很有用...) In...

    luckyw 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<