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的示例分析”有了一定的了解，如果想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！