MySQL配置瞭雙主,是如何避免出現數據回環沖突的

不知道大傢想過這個問題沒有?如果配置瞭雙主,是如何避免出現數據回環沖突的,因為在數據雙活的設計方案中,這可以算是方案的核心設計思想之一。

如果主庫觸發SQL語句:

insert into test_data(name) values(‘aa');

那麼Master1生成binlog,推送數據變化到Master2,在Master2上面生成relay log,然後交由sql thread進行變更重放,反之也是類似的流程,整個流程可以這樣描述。

如果Master2消費瞭relay的數據,然後會產生binlog(log_slave_updates默認開啟),這個時候產生的binlog會繼續推送到Master1消費,然後來來回回推送,一套insert語句就無窮無盡瞭,顯然這種設計是不合理的,MySQL也肯定不會這麼做。

那麼問題的關鍵的部分就是:Master2是否推送瞭先前的binlog到Master1?

a) 如果推送瞭,Master1是如何過濾,避免後續無限循環

b) 如果沒有推送,Master2是如何過濾的

如果要理解這個過程,我們就需要模擬測試,查看數據流轉過程中的binlog情況,可以參考這個流程。

1) Master1的binlog

2) Master2的 relay log

3) Master的binlog

很快就部署好瞭一套主從環境,然後添加change master to 就快速搭建好瞭一套測試的雙主環境。

為瞭盡可能看到完整的binlog事件信息,我們開啟參數binlog_rows_query_log_events

在Master1觸發語句:

insert into test_data(name) values(‘gg');

得到的binlog事件如下,可以清楚的看到相關的SQL語句。

在Master2端,我們查看binlog的情況,在開啟binlog_rows_query_log_events的前提下會看到明顯少瞭事件:Rows_query.

此時需要思考的是,在這個過程中偏移量是否發生瞭變化,從Master1產生的binlog到Master的relay log,如果通過mysqlbinlog去解析,得到的偏移量情況都是一模一樣,而在Master2消費後,產生瞭相關的binlog信息。

問題的關鍵就在這裡,在Maser2裡面是通過Server_id來標註瞭數據的源頭,所以在這裡就稱為整個數據流轉的終點瞭,也就意味著數據復制的時候是按照server_id來進行U過濾的,每個Master端隻會傳送自己相關的binlog信息。

如果從這個角度來說,MySQL對於復制中的server_id如此重要的一個原因就是基於此。

而如果換一個角度,看待基於偏移量的異步復制,其實也可以得到類似的信息。

這是Master1觸發insert語句後的binlog細節。

這是Master2接受實時數據後的binlog細節。

其實看到這裡,還存在一個問題,那就是在偏移量模式下,如果需要一個數據變更操作在Master2丟失瞭,那麼是沒有辦法進行回溯的。

而基於GTID模式可以唯一性標識全局事務,那麼哪怕對這個操作進行瞭重復應用,哪怕是DDL語句,操作的影響行數也是0.

我們對一個已經執行的操作進行再次應用,看看MySQL是否會自動舍棄該類操作。

mysql> SET @@SESSION.GTID_NEXT= '6fb744dd-05dd-11ea-ada7-52540043a8b5:6';

Query OK, 0 rows affected (0.00 sec)

mysql> use `test`; create table test_data (id int primary key auto_increment,name varchar(30));

Database changed

Query OK, 0 rows affected (0.00 sec)

查看show binlog events發現這個過程不會產生額外的binlog。

所以基於此,我們也基本明確瞭數據回環解決方法的一個設計思想,那就是如何讓MySQL能夠識別出那些已經應用的事務數據,我想GTID是一個答案,而且分佈式ID不用,這是MySQL內部的處理機制,而且是MySQL能夠識別的方式。

以上就是MySQL配置瞭雙主,是如何避免出現數據回環沖突的的詳細內容,更多關於MySQL 避免數據回環沖突的資料請關註WalkonNet其它相關文章!