MySQL 8.0新特征：彻底办理困扰运维的复制耽误题目，你信吗？

可以看到，因为是在一个Session中，这些操纵按着串行的次序有着差异的 last_committed，正常环境下，这些BinlogEvent应该在从机上同样以串行的方法回放。我们看一下在MGR集群中的RelayLog环境：

# mysqlbinlog mysql-relay.N | grep -e last_  |  sed -e 's/server id.*last/[...] last/' -e 's/.rbr_only.*/ [...]/'  
#180106 19:31:36 [...] last_committed=0 sequence_number=0 [...]  
#180106 19:31:36 [...] last_committed=1 sequence_number=2 [...] -- CREATE DB  
#180106 19:31:36 [...] last_committed=2 sequence_number=3 [...] -- CREATE TB  
#180106 19:31:36 [...] last_committed=3 sequence_number=4 [...] -- INSERT a  
#180106 19:31:36 [...] last_committed=3 sequence_number=5 [...] -- INSERT b  
#180106 19:31:36 [...] last_committed=3 sequence_number=6 [...] -- INSERT c 

风趣的是，在Secondary节点的RelayLog中, 这些事宜有着沟通的last_committed值，也就是嗣魅这些事宜在MGR集群中，回放的时辰可以以并行的方法回放。

MGR中，行使的正是WriteSet技能检测差异事宜之间是否存在写斗嘴，并重筹划了事宜的并行回放，这一技能在8.0中被移到了Binlog天生阶段，并回收到了主从复制的架构中。

四、MySQL 8.0中的并行复制

说了这么多，终于讲到了MySQL 8.0 ，通过以上描写，读者应该对MySQL 8.0中并行复制的优化的道理有了一个大抵的外观。通过基于WriteSet的斗嘴检测，在主机上发生Binlog的时辰，不再基于组提交，而是基于事宜自己的更新斗嘴来确定并行相关。

1、相干的MySQL参数

在MySQL 8.0中，该版本引入了参数binlog_transaction_depandency_tracking用于节制怎样抉择事宜的依靠相关。

该值有三个选项：

• 默认的COMMIT_ORDERE暗示继承行使5.7中的基于组提交的方法抉择事宜的依靠相关；
• WRITESET暗示行使写荟萃来抉择事宜的依靠相关；
• 尚有一个选项WRITESET_SESSION暗示行使WriteSet来抉择事宜的依靠相关，可是统一个Session内的事宜不会有沟通的last_committed值。

在代码实现上，MySQL回收一个vector<uint64>的变量存储已经提交的事宜的HASH值，全部已经提交的事宜的所修改的主键和非空的UniqueKey的值颠末HASH后与该vector中的值比拟，由此来判定当条件交的事宜是否与已经提交的事宜更新了统一行，并以此确定依靠相关。该向量的巨细由参数binlog_transaction_dependency_history_size节制，取值范畴为1-1000000 ，初始默认值为25000。

同时参数transaction_write_set_extraction节制检测事宜依靠相关时回收的HASH算法有三个取值OFF|XXHASH64|MURMUR32， 如binlog_transaction_depandency_tracking取值为WRITESET或WRITESET_SESSION，那么该值取值不能为OFF，且不能改观。

2、WriteSet 依靠检测前提

WriteSet是通过检测两个事宜是否更新了沟通的记录来判定事宜可否并行回放的，因此必要在运行时生涯已经提交的事宜信息以记录汗青事宜更新了哪些行。记录汗青事宜的参数为binlog_transaction_dependency_history_size。该值越大可以记录更多的已经提交的事宜信息，不外必要留意的是，这个值并非指事宜巨细，而是指追踪的事宜更新信息的数目。在开启了WRITESET或WRITESET_SESSION后，MySQL按以下的方法标识并记录事宜的更新。

假如事宜当前更新的行有主键（Primary Key），则将HASH（DB名、TABLE名、KEY名称、KEY_VALUE1、KEY_VALUE2……）插手到当前事宜的vector write_set中。

假如事宜当前更新的行有非空的独一键 （Unique Key Not NULL）， 同样将 HASH（DB名、TABLE名、KEY名、KEY_VALUE1）……插手到当前事宜的write_set中。

假如事宜更新的行有外键束缚( FOREIGN KEY )且不为空，则将该外键信息与VALUE 的HASH加到当前事宜的 write_set 中；假如事宜当前更新的表的主键是其余某个表的外键，则配置当前事宜 has_related_foreign_key = true；假如事宜更新了某一行且没有任何数据被插手到 write_set 中，则标志当前事宜 has_missing_key = true。

在执行斗嘴检测的时辰，先会搜查has_related_foreign_key和has_missing_key ， 假如为true，则退到COMMIT_ORDER模式；不然，会依照事宜的write_set中的HASH值与已提交的事宜的write_set举办比对。

假如没有斗嘴，则当前事宜与最后一个已提交的事宜共享沟通的last_commited，不然将从全局已提交的write_set中删除谁人斗嘴的事宜之条件交的全部write_set，并退化到COMMIT_ORDER计较last_committed 。

在每一次计较完事宜的last_committed值往后，必要去检测当前全局已经提交的事宜的write_set是否已经高出了binlog_transaction_dependency_history_size配置的值，假如高出，则清空已提交事宜的全局write_set。

从检测前提上看，该特征依靠于主键和独一索引，假如事宜涉及的表中没有主键且没有独一非空索引，那么将无法以后特征中得到机能的晋升。除此之外，还必要将Binlog名目配置为Row名目。

3、机能晋升

MySQL High Availability对开启了WriteSet的复制机能做了测试，这里直接将测试功效搬运过来，有乐趣的可以直接会见原博客。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!