小编给大家分享一下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的示例分析”有了一定的了解，如果想了解更多相关知识，欢迎关注创新互联行业资讯频道，感谢各位的阅读！
