第16节 基于WRITESET的并行复制方式

  • 时间:
  • 浏览:2

解析同上

实际上在函数add_pke中就会判断是否有主键只要 唯一键,只要 占据 唯一键也是无需 。Writeset中存储了唯一键的行数据hash值。参考函数add_pke,下面是判断:

这段描述的代码对应:

本参数默认值为2300000。代表的是大家 说的Writeset历史MAP中元素的个数。如前面分析的Writeset生成过程中修改一行数据只要 会生成多个HASH值,只要 这种 值还非要完整篇 停留于修改的行数,无需 理解为如下:

大家 通过前面的分析无需 发现只要 这种 值越大非要 在Writeset历史MAP中能容下的元素也就过多,生成的last commit就只要 更加精确(更加小),从库并发的速度单位也就只要 越高。只要 大家 非要注意设置越大相应的内存需求也就越高了。

只要 大家 在生成last commit会判断这种 设置如下:

下面是一段伪代码,用来描述这种 生成过程:

这种 行数据一共会生成有有另有一个 元素分别为:

大家 使用如下表:

根据binlog_transaction_dependency_tracking取值的不同会做进一步的除理,如下:

这里介绍一下整个除理的过程,假设如下:

每行数据的具体格式为:

大家 到这里只要 讨论了Writeset是哪几种,也只要 说过只要 要降低last commit的值大家 非要通过对事务的Writeset和Writeset的历史MAP进行比对,看是否冲突无需 决定降低为哪几种值。非要 非要在内存中保存一份从前的有有另有一个 历史MAP才行。在源码中使用如下法子定义:

前面说过这种 法子只要在WRITESET的基础上继续除理,实际上它的含义只要同有有另有一个 session的事务不允许在从库并行回放。代码很简单,如下:

大家 无需 看后其中的last commit看起来是乱序的,这种 状况在基于COMMIT_ORDER 的并行基因重组法子下是不只要 一直出现的。实际上它只要大家 前面说的基于WRITESET的并行基因重组再尽只要 降低的last commit的结果。这种 状况会在MTS从库获得更好的并行回放效果,第19节只要 完整篇 解释并行判定的标准。

集合中的每有有另有一个 元素还会hash值,这种 hash值和大家 的transaction_write_set_extraction参数指定的算法有关,其来源只要行数据的主键和唯一键。每行数据中有 了本身生活格式:

它们是在5.7.22才引入的。

前一节大家 讨论了基于ORDER_COMMIT的并行基因重组是怎么生成last_commit和seq number的。实际上基于WRITESET的并行基因重组法子只要在ORDER_COMMIT的基础上对last_commit做更进一步除理,从不影响原有的ORDER_COMMIT逻辑,只要 只要 要回退到ORDER_COMMIT逻辑非常方便。无需 参考MYSQL_BIN_LOG::write_gtid函数。

在Innodb层修改一行数据以还会将这上边的格式的数据进行hash后写入到Writeset中。无需 参考函数add_pke,上边我也会以伪代码的法子给出累积流程。

大家 无需 看后这是C++ STL中的map容器,它包中有 有另有一个 元素:

经过这种 操作后,大家 发现这种 状况最后last commit恢复成了ORDER_COMMIT的法子。

解析同上

有了前面的基础,大家 就很容易解释这种 问题图片了。其主要是因为只要Writeset的历史MAP的占据 ,只要哪几种事务修改的行非要 冲突,也只要主键/唯一键不相同,非要 在基于WRITESET的并行基因重组法子中就无需 占据 这种 问题图片,只要 只要 binlog_transaction_dependency_tracking设置为WRITESET_SESSION则无需一直出现这种 问题图片。

基于COMMIT_ORDER的并行基因重组非要在有压力的状况下才只要 会形成一组,压力不大的状况下在从库的并行度从无需高。只要 基于WRITESET的并行基因重组目标只要在ORDER_COMMIT的基础上再尽只要 的降低last commit,从前在从库获得更好的并行度(即便在主库串行执行的事务在从库无需 并行应用)。它使用的法子只要通过扫描Writeset中的每有有另有一个 元素(行数据的hash值)在有有另有一个 叫做Writeset的历史MAP(行数据的hash值和seq number的有有另有一个 MAP)中进行比对,寻找是否有冲突的行,只要 做相应的除理,上边大家 会完整篇 描述这种 行为。只要 要使用这种 法子大家 非要在主库设置如下有有另有一个 参数:

整个过程现在现在现在开始。last commit由以前的125降低为120,目的达到了。实际上大家 无需 看出Writeset历史MAP就离米 保存了一段时间以来修改行的快照,只要 保证本次事务修改的数据在这段时间内非要 冲突,非要 显然是无需 在从库并行执行的。last commit降低后如下图(图16-2,高清原图中有 在文末原图中):

最终哪几种数据会通过hash算法后写入到Writeset中。

只要 从库非要 延迟,则不非要考虑这种 法子,即便有延迟大家 也应该先考虑许多方案。第28节大家 只要 描述有哪几种是因为延迟的只要 。

实际上Writeset是有有另有一个 集合,使用的是C++ STL中的set容器,在类Rpl_transaction_write_set_ctx中中有 了如下定义:

更多主从同步相关无需 参考我的《深入理解MySQL主从原理 32节》专栏:

为了更直观的观察到这种 数据格式,无需 使用debug的法子获取。下面大家 来看一下。

只要 非要 主键只要 唯一键非要 下面话语将被触发:

分解为:

它是按照Writeset的hash值进行排序的。

大家 先来看有有另有一个 截图,仔细观察其中的last commit:

初始化状况如下图(图16-1,高清原图中有 在文末原图中):

只要 非要 主键无需 使用唯一键,只要 都非要 话语WRITESET设置就无需生效回退到老的ORDER_COMMIT法子。

大家 写入一行数据:

整个逻辑就在函数Writeset_trx_dependency_tracker::get_dependency中,下面是许多关键代码,代码稍多:

其次内存中还维护有有另有一个 叫做m_writeset_history_start的值,用于记录Writeset的历史MAP中最早事务的seq number。只要 Writeset的历史MAP满了就会清理这种 历史MAP只要 将本事务的seq number写入m_writeset_history_start,作为最早的seq number。上边会看后对于事务last commit的值的修改一直从这种 值现在现在现在开始只要 进行比较判断修改的,只要 在Writeset的历史MAP中非要 找到冲突非要 直接设置last commit为什么我儿 m_writeset_history_start值即可。下面是清理Writeset历史MAP的代码:

注意:本文分为正文和附件两累积,还会图片格式,只要 正文有图片不清晰无需 将附件的图片保存到本地查看。

分解为:

好了到这里大家 明白了基于WRITESET的并行基因重组法子的优点,只要 它还会明显的缺点如下:

第16节现在现在现在开始

只要 非要注意有有另有一个 事务的所有的行数据的hash值还会写入到有有另有一个 Writeset。只要 修改的行比较多非要 只要 非要更多内存来存储哪几种hash值。真是8字节比较小,只要 只要 有有另有一个 事务修改的行许多,非要 还是非要消耗较多的内存资源的。

注意:这里显示的?是分隔符