在日常運維中，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。

(6)一旦在給定的MySQL實例中提交了事務，具有相同GTID的事務便會被該服務器忽略。而且，在主實例上提交的事務在從庫上只可以應用一次。

-----主要內容參考梳理于網絡知識，此短文僅為學習筆記，在此原創作者感謝！