MySQL中基于WRITESET的并行复制方式是什么

本篇内容主要讲解“MySQL中基于WRITESET的并行复制方式是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MySQL中基于WRITESET的并行复制方式是什么”吧!我们先来看一个截图，仔细观察其中的last commit：
我们可以看到其中的last commit看起来是乱序的，这种情况在基于COMMIT_ORDER 的并行复制方式下是不可能出现的。实际上它就是我们前面说的基于WRITESET的并行复制再尽可能降低的last commit的结果。这种情况会在MTS从库获得更好的并行回放效果，第19节将会详细解释并行判定的标准。实际上Writeset是一个集合，使用的是C++ STL中的set容器，在类Rpl_transaction_write_set_ctx中包含了如下定义：集合中的每一个元素都是hash值，这个hash值和我们的transaction_write_set_extraction参数指定的算法有关，其来源就是行数据的主键和唯一键。每行数据包含了两种格式：字段值为二进制格式字段值为字符串格式每行数据的具体格式为：在Innodb层修改一行数据之后会将这上面的格式的数据进行hash后写入到Writeset中。可以参考函数ad免费主机域名d_pke，后面我也会以伪代码的方式给出部分流程。但是需要注意一个事务的所有的行数据的hash值都要写入到一个Writeset。如果修改的行比较多那么可能需要更多内存来存储这些hash值。虽然8字节比较小，但是如果一个事务修改的行很多，那么还是需要消耗较多的内存资源的。为了更直观的观察到这种数据格式，可以使用debug的方式获取。下面我们来看一下。我们使用如下表：我们写入一行数据：这一行数据一共会生成4个元素分别为：注意：这里显示的?是分隔符分解为：分解为：
| 主键名称 | 分隔符 | 库名 | 分隔符 |库名长度 | 表名 |分隔符|表名长度|主键字段1|分隔符|长度 |
| ——— | ——— | ——— | ——— | ——— | ——— | ——— | ——— | ——— |——— |———|
| PRIMARY |?| test|?|4|jj10|?|4|36 | ?|2|解析同上解析同上最终这些数据会通过hash算法后写入到Writeset中。下面是一段伪代码，用来描述这种生成过程：前一节我们讨论了基于ORDER_COMMIT的并行复制是如何生成last_commit和seq number的。实际上基于WRITESET的并行复制方式只是在ORDER_COMMIT的基础上对last_commit做更进一步处理，并不影响原有的ORDER_COMMIT逻辑，因此如果要回退到ORDER_COMMIT逻辑非常方便。可以参考MYSQL_BIN_LOG::write_gtid函数。根据binlog_transaction_dependency_tracking取值的不同会做进一步的处理，如下：ORDER_COMMIT：调用m_commit_order.get_dependency函数。这是前面我们讨论的方式。WRITESET：调用m_commit_order.get_dependency函数，然后调用m_writeset.get_dependency。可以看到m_writeset.get_dependency函数会对原有的last commit做处理。WRITESET_SESSION：调用m_commit_order.get_dependency函数，然后调用m_writeset.get_dependency再调用m_writeset_session.get_dependency。m_writeset_session.get_dependency会对last commit再次做处理。这段描述的代码对应：我们到这里已经讨论了Writeset是什么，也已经说过如果要降低last commit的值我们需要通过对事务的Writeset和Writeset的历史MAP进行比对，看是否冲突才能决定降低为什么值。那么必须在内存中保存一份这样的一个历史MAP才行。在源码中使用如下方式定义：我们可以看到这是C++ STL中的map容器，它包含两个元素：Writeset的hash值最新一次本行数据修改事务的seq number它是按照Writeset的hash值进行排序的。其次内存中还维护一个叫做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的代码：这里介绍一下整个处理的过程，假设如下：当前通过基于ORDER_COMMIT的并行复制方式后，构造出来的是（last commit=125，seq number=130）。本事务修改了4条数据，我分别使用ROW1/ROW7/ROW6/ROW10代表。表只包含主键没有唯一键，并且我的图中只保留行数据的二进制格式的hash值，而没有包含数据的字符串格式的hash值。初始化情况如下图（图16-1，高清原图包含在文末原图中）：
第一步 设置last commit为writeset_history_start的值也就是100。第二步 ROW1.HASHVAL在Writeset历史MAP中查找，找到冲突的行ROW1.HASHVAL将历史MAP中这行数据的seq number更改为130。同时设置last commit为120。第三步 ROW7.HASHVAL在Writeset历史MAP中查找，找到冲突的行ROW7.HASHVAL将Writeset历史MAP中这行数据的seq number更改为130。由于历史MAP中对应的seq number为114，小于120不做更改。last commit依旧为120。第四步 ROW6.HASHVAL在Writeset历史MAP中查找，找到冲突的行ROW6.HASHVAL将Writeset历史MAP中这行数据的seq number更改为130。由于历史MAP中对应的seq number为105，小于120不做更改。last commit依旧为120。第五步 ROW10.HASHVAL在Writeset历史MAP中查找，没有找到冲突的行，因此需要将这一行插入到Writeset历史MAP中查找（需要判断是否导致历史MAP占满，如果占满则不需要插入，后面随即要清理掉）。即要将ROW10.HASHVAL和seq number=130插入到Writeset历史MAP中。整个过程结束。last commit由以前的130降低为120，目的达到了。实际上我们可以看出Writeset历史MAP就相当于保存了一段时间以来修改行的快照，如果保证本次事务修改的数据在这段时间内没有冲突，那么显然是可以在从库并行执行的。last commit降低后如下图（图16-2，高清原图包含在文末原图中）：
整个逻辑就在函数Writeset_trx_dependency_tracker::get_dependency中，下面是一些关键代码，代码稍多：前面说过这种方式就是在WRITESET的基础上继续处理，实际上它的含义就是同一个session的事务不允许在从库并行回放。代码很简单，如下：经过这个操作后，我们发现这种情况最后last commit恢复成了ORDER_COMMIT的方式。本参数默认值为25000。代表的是我们说的Writeset历史MAP中元素的个数。如前面分析的Writeset生成过程中修改一行数据可能会生成多个HASH值，因此这个值还不能完全等待于修改的行数，可以理解为如下：binlog_transaction_dependency_history_size/2=修改的行数 * （1+唯一键个数）我们通过前面的分析可以发现如果这个值越大那么在Writeset历史MAP中能容下的元素也就越多，生成的last commit就可能更加精确（更加小），从库并发的效率也就可能越高。但是我们需要注意设置越大相应的内存需求也就越高了。实际上在免费主机域名函数add_pke中就会判断是否有主键或者唯一键，如果存在唯一键也是可以。Writeset中存储了唯一键的行数据hash值。参考函数add_pke，下面是判断：如果没有主键或者唯一键那么下面语句将被触发：然后我们在生成last commit会判断这个设置如下：因此没有主键可以使用唯一键，如果都没有的话WRITESET设置就不会生效回退到老的ORDER_COMMIT方式。有了前面的基础，我们就很容易解释这种现象了。其主要原因就是Writeset的历史MAP的存在，只要这些事务修改的行没有冲突，也就是主键/唯一键不相同，那么在基于WRITESET的并行复制方式中就可以存在这种现象，但是如果binlog_transaction_dependency_tracking设置为WRITESET_SESSION则不会出现这种现象。到此，相信大家对“MySQL中基于WRITESET的并行复制方式是什么”有了更深的了解，不妨来实际操作一番吧！这里是云技术网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！

相关推荐: 如何汇总上百台mysql的慢日志

这篇文章将为大家详细讲解有关如何汇总上百台mysql的慢日志，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。 生产环境有很多模块用的数据库是MySQL,一个模块下用的最多得MySQL达到36台（包含主从，主从均参与读）。为了更…