MYSQL Write Set的示例分析

小编给大家分享一下MYSQL Write Set的示例分析，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！

基于MYSQL 的组复制，其实已经是一项成熟的技术了，从MYSQL 5.6 开始，到目前的8 ，属于接近初成熟的阶段。

但到底 GROUP REPLICATION 到底为什么比传统的主从复制要快，这是一个问题。我们现在就来说说为什么组复制要比你的传统复制快。

首先我们要理解两个事情，为什么要组复制，理由无非两个

1  提供成员之间更快的复制

2  提供多成员之间的认证

到底WRITE-SET 比原先的复制哪里快了

首先我们要了解几个问题和相关的参数

binlog_transaction_dependency_tracking  

这个参数有三个设置的选择项

1 commit_order   默认值，在从库进行顺序型的应用

2 writeset 依赖主库的事务的关联性，在从库可以进行非顺序型的并行应用

3 writeset_session 和第二点的不同在于SESSION的隔离性

 我们可以比对 commit_order 和  writeset_session 之间的区别

首先我们可以创建一个表，并插入记录，然后观察LOG 中两个不同的参数的变化。

CREATE DATABASE test;

CREATE TABLE test ( id int NOT NULL AUTO_INCREMENT PRIMARY KEY,  text varchar(80) );

 insert into test (text) values ('3dsjfuiuiree');

insert into test (text) values ('3dereresdfere');

insert into test (text) values ('vcdreresdfere');

我们可以看图，5个操作进行 last_committed 可以很明显的看到前两个操作是不能进行组提交的，而后面三个是可以进行组提交的。

如果我们改变相关的设置，改为order_commit ，三台组复制的机器上都更改了，但是结果和预想的不一样，根本没有用，提交的的时候无论你是更改成 commit_order ,还是  binlog_tranaction_dependency_history_size  设置为 1 都不能阻挡 MGR 的组提交方式。

而令我疑惑的是 binlog_tranaction_dependency_history_size 本身就是一个内存的hash ，我已经将其调整为1  ，怎么会commit 的

If we use dependency tracking using WRITESETs on the master, those writesets are preserved over time, up to a maximum history size, and then the dependency information is generated based on that. 

所有我的测试对象又转移到，传统的GTID 复制的机器上面， 两台机器然后最简单的主从复制，然后将复制的方式改为

set global binlog_transaction_dependency_tracking = writeset

然后去观察relay log 发现怎么样都不是组提交的方式，还是按照commit_order的方式进行提交 。

看完了这篇文章，相信你对“MYSQL Write Set的示例分析”有了一定的了解，如果想了解更多相关知识，欢迎关注亿速云行业资讯频道，感谢各位的阅读！