共計 6216 個字符，預計需要花費 16 分鐘才能閱讀完成。

本篇內容主要講解“Mysql 5.7 中 Gtid 帶來的運維改變分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“Mysql 5.7 中 Gtid 帶來的運維改變分析”吧!

一、如何跳過一個事物

和傳統基于位置的主從不同，如果從庫報錯我們需要獲得從庫執行的最后一個事物，方法有如下：

show slave status \G 中的 Executed_Gtid_Set。

show global variables like %gtid% 中的 gtid_executed。

show master status; 中的 Executed_Gtid_Set。

然后構建一個空事物如下：

stop slave ;
set gtid_next= 4a6f2a67-5d87-11e6-a6bd-000c29a879a3:34 
begin;commit;
set gtid_next= automatic 
start slave ;

如果是多個如下：

stop slave ;
set gtid_next= 89dfa8a4-cb13-11e6-b504-000c29a879a3:3 
begin;commit;
set gtid_next= 89dfa8a4-cb13-11e6-b504-000c29a879a3:4 
begin;commit;
set gtid_next= automatic 
start slave ;

二、mysqldump 導出行為的改變

使用 mysqldump 受到選項 set-gtid-purged=AUTO 的影響，假如我們在 Gtid 開啟和關閉的情況下使用如下語句導出數據：

mysqldump --single-transaction --master-data=2 -R -E --triggers --all-databases

在 Gtid 開啟的情況下會多如下設置：

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
-- GTID state at the beginning of the backup 
SET @@GLOBAL.GTID_PURGED= ec9bdd78-a593-11e7-9315-5254008138e4:1-105

為什么要這么設置呢？因為如果做基于 Gtid 的主從，是否生成 binlog 就意味著在導入數據的時候是否基于本地數據庫生成新的 Gtid 事物，顯然這是不合理的，所以將 SQL_LOG_BIN 設置為 0 是必須的。接著 GTID_PURGED 被設置為備份時刻已經執行過的 Gtid 事物，如前文第五節源碼剖析設置 GTID_PURGED 會設置三個地方的 Gtid 如下:

mysql.gtid_executed 表

gtid_purge 變量

gtid_executed 變量

看起來是合理的，但是如果這里忽略了整個 mysql.gtid_executed 表是 innodb 表，導入過程中某些版本 (已知 percona 5.7.14，5.7.17) 會重新刪除和建立，因此通過 GTID_PURGED 設置的 mysql.gtid_executed 表會重新改變，重啟數據庫后需要讀取 mysql.gtid_executed 表可能獲得錯誤 Gtid 集合導致復制錯誤。這也為我的故障案例埋下了伏筆，案例中在詳細描述。
當然也可以使用 –set-gtid-purged=OFF 選項來告訴 mysqldump 不需要加入 SQL_LOG_BIN= 0 和 GTID_PURGED，但是初始化搭建基于 Gtid 的主從一定不要設置為 OFF。下面是這個選項的含義。

 --set-gtid-purged[=name] 
 Add  SET @@GLOBAL.GTID_PURGED  to the output. Possible
 values for this option are ON, OFF and AUTO. If ON is
 used and GTIDs are not enabled on the server, an error is
 generated. If OFF is used, this option does nothing. If
 AUTO is used and GTIDs are enabled on the server,  SET
 @@GLOBAL.GTID_PURGED  is added to the output. If GTIDs
 are disabled, AUTO does nothing. If no value is supplied
 then the default (AUTO) value will be considered.

三、5.7 中搭建基于 Gtid 的主從

這里存在一個注意點，也是我案例中會提到的。我們還是直接說步驟

注意主備庫必須開啟 Gtid 和設置好 server_id

 enforce_gtid_consistency = ON
 gtid_mode = ON
 server_id = 9910
 binlog_format = row

同時主備庫都開啟 binlog 如果不設置級聯從庫，從庫不要設置 log_slave_updates 參數。
這是最合理的設置。

建立復制用戶

CREATE USER  repl @ %  IDENTIFIED BY  test123 
GRANT REPLICATION SLAVE ON *.* TO  repl @ %  ;

導出數據

mysqldump --single-transaction --master-data=2 -R -E --triggers --all-databases   test.sql

從庫導入數據
source 即可。

從庫執行 reset master 語句
這一步主要防止 gtid_executed 被更改過。這個問題在在 percona 5.7.14 5.7.17 存在但是在 percona 5.7.15 5.7.19 又不存在。所以為了安全還是執行下面的兩步。

reset master；

提取 GTID_PURGED，并且執行
使用 head -n 40 命令可以快速的得到比如我這里的

--
-- GTID state at the beginning of the backup 
SET @@GLOBAL.GTID_PURGED= ec9bdd78-a593-11e7-9315-5254008138e4:1-21

執行

SET @@GLOBAL.GTID_PURGED= ec9bdd78-a593-11e7-9315-5254008138e4:1-21

語句即可，完成本部分 mysql.gtid_executed 表會重構。

使用 MASTER_AUTO_POSITION 建立同步

change master to 
master_host= 192.168.99.41 ,
master_user= repl ,
master_password= test123 ,
master_port=3310,
MASTER_AUTO_POSITION = 1;

啟動 slave

start slave

四、5.7 中 Gtid 的主從的切換

切換中必須要確認從庫 (新主庫) 沒有做過本地的事物，如果做過，否則切換主庫 (新從庫) 需要拉取這一部分的 Gtid 事物，如果這些 binlog 已經不存在了那么勢必會報錯。這種情況下還是從建從庫吧。那么我們來說正常的切換步驟。

從庫(新主庫)

stop slave;
reset slave all;

主庫(新從庫)

change master to 
master_host= 192.168.99.40 ,
master_user= repl ,
master_password= test123 ,
master_port=3310,
MASTER_AUTO_POSITION = 1;
start slave;

實際就這么簡單，從庫 (新主庫) 會生成自己的 Gtid 事物，新主庫接受到后執行即可。此時會出現如下有兩個 server_uuid 對應的 Gtid，如下的 gtid_executed

mysql  show global variables like  %gtid% 
+----------------------------------+-------------------------------------------------------------------------------------+
| Variable_name | Value |
+----------------------------------+-------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 31704d8a-da74-11e7-b6bf-525400a7d243:1-9,
ec9bdd78-a593-11e7-9315-5254008138e4:1-25 |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | ec9bdd78-a593-11e7-9315-5254008138e4:1-25 |
| session_track_gtids | OFF |
+----------------------------------+-------------------------------------------------------------------------------------+

總的說來如果要作為的切換的從庫，不要在從庫本地做任何事物。如果確實要做比如加索引等不影響數據的操作可以是使用如下：

mysql  set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
mysql  create index test_jjj on jjj(id);
Query OK, 0 rows affected (0.42 sec)
Records: 0 Duplicates: 0 Warnings: 0

這樣也是不會增加本地 Gtid 的。

五、在線修改 Gtid 模式

這是 5.7.6 以后實現的功能其主要依賴了我們前面分析的 Previous gtid Event 以及參數 gtid_mode 新加入的 2 個值。我們具體來看看 gitd_mode 各個值的含義：

OFF(0): Both new and replicated transactions must be anonymous.(生成的是匿名事物，slave 也只能應用匿名事物)

OFF_PERMISSIVE:(1) New transactions are anonymous. Replicated transactions can be either
anonymous or GTID transactions.(生成的是匿名事物，slave 可以應用匿名和 GTID 事物)

ON_PERMISSIVE(2): New transactions are GTID transactions. Replicated transactions can be either
anonymous or GTID transactions.(生成的是 GTID 事物，slave 可以應用匿名和 GTID 事物)

ON(3): Both new and replicated transactions must be GTID transactions(生成的是 GTID 事物，slave 也只能應用 GTID 事物)

注意每次修改值必然導致一次 binlog 的切換，如果發生 binlog 刪除也能夠依托 Previous gtid Event 快速準確的找到 gtid_purged(Gtid_state.lost_gtids)。

在線啟動

主庫 / 從庫執行

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;

確定事物都支持 gtid，不會在 err log 中出現警告如下：
2017-02-26T22:35:24.322055Z 55 [Warning] Statement violates GTID consistency: CREATE TABLE … SELECT.

主庫 / 從庫執行

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;

主庫 / 從庫執行

SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

生成的是匿名事物，slave 可以應用匿名和 GTID 事物

主庫 / 從庫執行

SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

生成的是 GTID 事物，slave 可以應用匿名和 GTID 事物

主庫 / 從庫執行

確定已經沒有匿名的事物

SHOW GLOBAL STATUS LIKE  ONGOING_ANONYMOUS_TRANSACTION_COUNT

同時確認從庫
Retrieved_Gtid_Set
Executed_Gtid_Set
正常增長

到這一步實際上 gtid 事物已經開始使用了。

主庫 / 從庫執行

SET @@GLOBAL.GTID_MODE = ON;

從庫執行

stop slave;
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
start slave;

主庫 / 從庫執行
修改配置文件 my.cnf，將參數的更改加入到配置文件

在線關閉

從庫執行

stop slave;

記錄從庫執行狀態值

Exec_Master_Log_Pos: 7631438
Relay_Master_Log_File: bin_log.000016

執行

CHANGE MASTER TO MASTER_AUTO_POSITION = 0,
MASTER_LOG_FILE =  bin_log.000016 , 
MASTER_LOG_POS = 7631438
start slave;

主庫 / 從庫執行

SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

生成的是 GTID 事物，slave 可以應用匿名和 GTID 事物

主庫 / 從庫執行

SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

生成的是匿名事物，slave 可以應用匿名和 GTID 事物

從庫執行

等待從庫
Retrieved_Gtid_Set
Executed_Gtid_Set
不再變動。
完成這一步實際上 GTID 事物已經沒有生成和應用了

主庫 / 從庫執行

SET @@GLOBAL.GTID_MODE = OFF;

主庫 / 從庫執行

修改配置文件 my.cnf，將參數的更改加入到配置文件

到此，相信大家對“Mysql 5.7 中 Gtid 帶來的運維改變分析”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！