在日常運維中，GTID帶來的最方便的作用就是搭建和維護主從複製。GTID的主從模式代替了MySQL早期版本中利用二進位日誌文件的名稱和日誌位置的做法，使用GTID使操作和維護都變得更加簡潔和可高。 1.GTID的優點 （1）基於GTID搭建主從複製根據簡單。 （2）可以確保每個事務只會被執行一次。 ...
在日常運維中，GTID帶來的最方便的作用就是搭建和維護主從複製。GTID的主從模式代替了MySQL早期版本中利用二進位日誌文件的名稱和日誌位置的做法，使用GTID使操作和維護都變得更加簡潔和可高。
1.GTID的優點
（1）基於GTID搭建主從複製根據簡單。
（2）可以確保每個事務只會被執行一次。
（3）可以方便的實現Replication的Failover，不需要像傳統模式複製那樣去找master_log_file和master_log_pos。
（4）GTID在MGR中也發揮了中要作用。MGR各節點之間複製依賴於GTID，並且在集群節點進行Recover重新加入到集群的操作中，會選擇其中一個節點作為Donor,然後基於Purged的GTID開始同步數據。MGR還是通過GTID進行衝突驗證，用於跟蹤每個實例上提交的事務，確定哪些事務可能有衝突。
2.使用GTID搭建主從時，需要註意的MySQL參數。
（1）server_id: 設置MySQL實例的server_id,每個實例的server_id不能一樣。
（2）gtid_mod=ON: MySQL實例開啟GTID模式。
（3）enforce_gtid_consitency=ON: 使用GTID模式複製時，需要開啟此參數，用來保證GTID的一致性。
（4）log-bin: MySQL必須開啟Binlog。
（5）log-slave-updates=1： 決定slave從master接受到的更新且執行之後，執行的Binlog是否記錄到salve的Binlog中，建議開啟。
（6）binlog_format=ROW：強烈建議binlog_format使用ROW格式，其它格式可能造成數據不一致。
（7）skip-slave-start=1：當salve資料庫啟動的時候，salve不會自動開啟複製。
3.使用GTID的註意事項
由於基於GTID的複製依賴於事務，所以在使用GTID時，有些MySQL特性不支持。
（1）事務中混合多個存儲引擎，會產生多個GTID。
當使用GTID時，如果在同一個事務中，更新包含了非事務引擎（如MyISAM）和事務引擎（InnoDB）表的操作，就會導致多個GTID分配給同一個事務。
（2）主從庫的表存儲引擎不一致，會導致數據不一致。
如果主從庫的存儲引擎不一致，例如一個是事務存儲引擎，一個是非事務存儲引擎，則會導致事務和GTID之間一對一的關係被破壞，結果導致基於GTID的複製不能正確地運行。
（3）基於GTID模式複製，不支持Create table ...select 語句。
因為使用基於行模式的複製時，該語句實際上被記錄為兩個單獨的事件，一個是創建表，另一個是將原表中的數據插入到剛剛新建的表中。當在事務中執行該語句時，在一些情況下。這兩個事務可能接收到相同的事務ID，這意味著包含插入的事務將被從庫挑過。
（4）不支持Create Temporary table 和 drop temporary table。
使用GTID複製時， 不支持Create Temporary table 和 drop temporary table。但是，在autocommit=1的情況下可以創建臨時表，master創建臨時表不產生GTID信息，所以不會同步到Salve上，但是刪除臨時表時，產生GTID會導致主從中斷。
（5）不推薦在GTID模式的實例上進行mysql_upgrade.
因為mysql_upgrade的過程要創建或修改系統表，而系統表時非事務引擎，所以不建議在開啟GTID模式的實例上使用帶有--write-binlog選項的mysql_upgrade。
-----主要內容參考梳理於網路知識，此短文僅為學習筆記，在此原創作者感謝！
