MySQL 基礎知識梳理學習（四）----GTID

在平常運維中，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的事務便會被該服務器忽略。並且，在主實例上提交的事務在從庫上只能夠應用一次。

 

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