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參數的語法。

感謝你們多多支持老張的新書，也感謝MySQL給咱們帶來的最淳樸，最簡單的快樂！

最後的最後