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的方式进行提交 。

原文发布于微信公众号 - AustinDatabases(AustinDatabases)

原文发表时间:2019-05-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券