在日常運維中，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。
—–主要內容參考梳理於網路知識，此短文僅為學習筆記，在此原創作者感謝！