GTID！MySQL複製中的核武器

各位老鐵們，本週老張的《MySQL王者晉級之路》一書終於出版了，現在可以預購啦！
預購鏈接地址：老張的數據庫微店
前前後後經歷了一年的準備時間，可謂十年磨一劍，把自己從業所有的精華和心血都灌輸到其書中。其書中包含了MySQL方方面面的知識點，是之前我的一篇博客“從青銅到王者，快速提升你MySQL數據庫段位的全面深入剖析”。用一句學生對我說得話，老師喜歡您的王者榮耀情懷，但更喜歡您的技術情操。講真，不要錯過！特別感謝在我從事技術道路上，幫助過我的前輩及兄弟們，這條路上的所有的辛酸，只有你們最懂我！也要感謝對我博客一直支持的兄弟們！

今兒的這篇博文，可以讓大家快速瞭解GTID特性，並能靈活地運用到生產環境中，希望對大家有幫助。

GTID原理介紹
GTID又叫全局事務ID（Global Transaction ID），是一個已提交事務的編號，並且是一個全局唯一的編號。MySQL5.6版本之後在主從複製類型上新增了GTID複製。
GTID是由server_uuid和事務id組成的，即GTID = server_uuid:transaction_id。 server_uuid是在數據庫啓動過程中自動生成的，每臺機器的server-uuid不一樣。uuid存放在數據目錄的auto.cnf文件下。而transaction_id就是事務提交時由系統順序分配的一個不會重複的序列號。

GTID存在的價值
（1）GTID使用master_auto_position=1代替了基於binlog和position號的主從複製搭建方式，更便於主從複製的搭建。
（2）GTID可以知道事務在最開始是在哪個實例上提交的。
（3）GTID方便實現主從之間的failover，再也不用不斷地去找position和binlog 了。

主從複製中GTID的管理與維護
GTID帶來最方便的一點就是主從複製的搭建過程了。它跟異步複製、半同步複製類似，只不過不再利用傳統複製模式的binlog文件和position號了，而是在從庫“change master to”時使用master_auto_position=1的方式進行搭建，這就讓操作變得更加方便和可靠。

GTID搭建過程中的注意事項
主從庫需要設置的參數如下。
主庫配置：

gtid_mode=on
enforce_gtid_consistency=on
log_bin=on

server-id不能與從庫一樣。

binlog_format=row

從庫配置：

gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1

雖然在MySQL5.7版本之後可以關閉掉log_slave_updates，使用gtid_executed這張表。但還是建議在從庫中開啓。server-id不能與主庫一樣。
配置好參數之後，主庫也創建了複製賬號，如果是新搭建的主從環境，就可以直接在從庫就可以執行change master to語句了。如果是已經運行了一段期間的主庫，還需要利用備份方式從主庫“dump”出數據到從庫中，先完成基於某個點的GTID複製，然後從庫從那個點之後再開始追主庫。利用mysqldump備份，備份後的文件中會有SET @@GLOBAL.GTID_PURGED= *，利用xtrabackup工具備份，備份後的文件中會直接記錄需要跳過的GTID。啓動複製之後，從庫會直接跳過已經執行過GTID的範圍，直接從主庫獲取新的GTID信息。
在主庫執行show master status命令，通過Executed_Gtid_Set來查看執行過的GTID。

在MySQL5.7版本之後，gtid_executed這個值持久化了。在MySQL庫下新增了一張表gtid_executed：

該表會記錄已經執行的GTID集合的信息，有了這張表，就不用再像MySQL5.6版本時，必須開啓log_slave_updates參數，從庫纔可以進行復制。GTID信息會保存在gtid_executed表中，可以關閉從庫的binlog，節約binlog的記錄開銷。在執行reset master時，會清空表內所有的數據。
MySQL5.7還有一個參數gtid_executed_compression_period，用來控制gtid_executed表的壓縮。該參數默認值爲1000，意味着表壓縮在執行完1000個事務之後開始。

從MySQL5.7.6開始，gtid_mode支持動態修改，gtid_mode可取值爲：
OFF—不支持GTID的事務；
OFFPERMISSIVE—新的事務是匿名的，同時允許複製的事務可以是GTID，也可以是匿名的；
ON PERMISSIVE—新的事務使用GTID，同時允許複製的事務可以是GTID，也可以是匿名的；
ON—支持GTID的事務。
在生產環境中，可能有把傳統複製改爲GTID的複製模式的需求。這裏特意強調一點，gtidmode雖然支持動態修改，但不支持跳躍式修改。從ON PERMISSIVE修改爲OFF是不可以的。下面會有實驗來展示傳統複製與GTID複製之間的切換過程。
在從庫上可通過show slave status命令來獲取接收的gtid（retrieve_gtid_set）和執行的gtid（execute_gtid_set）。

GTID複製與傳統複製的切換
前面已經搭建好了MySQL5.7版本的GTID複製模式，下面先來操作從GTID複製模式切換爲傳統複製模式的過程。
環境介紹：主庫爲192.168.56.101，從庫爲192.168.56.102。
當前主從狀態展示。

實施過程如下：

（1）先在從庫中執行stop slave，停掉主從複製。然後調整爲傳統複製模式，讓master_auto_position=0。
執行如下命令：
CHANGE MASTER TO master_auto_position=0,Master_Host='192.168.56.101',MASTER_USER='bak',MASTER_PASSWORD='bak123','Master_Log_File='mysql-binlog.000002',MASTER_LOG_POS=1141;
執行完成之後，開啓複製功能start slave。
（2）需要在主從服務器上同時調整GTID模式爲on_permissive。

（3）需要在主從服務器上同時調整GTID模式爲off_permissive。

（4）需要在主從服務器上同時關閉GTID功能。

（5）然後把gtid_mode=off和enforce_gtid_consistency=off寫入配置文件my.cnf中。下次重啓直接生效。
（6）測試是否切換成功。
首先向主庫的zs庫下的tt表中插入一條數據：

查看從庫，這條數據同步成功。

然後在從庫中執行show slave status查看主從複製狀態，發現GTID的值沒有增加，證明切換成功：

然後再操作從傳統複製模式切換爲GTID複製模式的過程。
實施過程如下：
（1）在主從庫上同時修改參數enforce_gtid_consistency=warn，確保在error log中不會出現警告信息。如果有，需要先修復，才能往後繼續執行。

（2）在主從服務器上把enforce_gtid_consistency改爲on，保證GTID的一致性。

（3）在主從服務器上同時調整GTID模式爲off_permissive。

（4）在主從服務器上同時調整GTID模式爲on_permissive。

（5）確認從庫的Ongoing_anonymous_transaction_count參數是否0，如果爲0，意味着沒有等待的事務，可以直接進行下一步操作了。

（6）在主從庫上同時設置gtid_mode=on。

查看GTID參數設置，目前都是開啓狀態。

（7）把傳統複製模式改爲GTID複製。先要把原有的傳統複製停掉，執行stop slave操作，然後再執行change master to master_auto_position=1。
執行完stop slave，查看當前主從的狀態爲：

然後再執行change master to master_auto_position=1，開啓主從複製start slave。
（8）驗證是否切換成功。
首先向主庫的zs庫下的tt表中插入一條數據：

查看從庫，這條數據同步成功。

然後在從庫中執行show slave status查看主從複製狀態，發現GTID的值增加了。證明開啓了GTID複製方式，切換成功。

GTID使用中的限制條件
GTID複製是針對事務來說的，一個事務只對應一個GTID，好多的限制就在於此。
（1）不能使用create table table_name select * from table_name。
（2）在一個事務中既包含事務表的操作又包含非事務表。
（3）不支持CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE語句操作。
（4）使用GTID複製從庫跳過錯誤時，不支持執行該sql_slave_skip_counter參數的語法。