mysql之 MySQL 主從基於 GTID 復制原理概述
一、 什麽是GTID （ Global transaction identifiers ）：
MySQL-5.6.2開始支持，MySQL-5.6.10後完善，GTID 分成兩部分，一部分是服務的UUid,UUID保存在mysql數據目錄的auto.cnf文件中,
這是一個非常重要的文件，不能刪除，這一部分是不會變的。另外一部分就是事務ID了，隨著事務的增加，值一次遞增,如下圖
+---------------+----------+--------------+------------------+--------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
| binlog.000029 | 23556 | | | 724afcc2-29d6-11e4-9902-000c290c0121:1-362 |
+---------------+----------+--------------+------------------+--------------------------------------------+
UUID:724afcc2-29d6-11e4-9902-000c290c0121
transactionId:1-362
在整個復制架構中GTID 是不變化的,即使在多個連環主從中也不會變。
例如：ServerA --->ServerB ---->ServerC
GTID從在ServerA ,ServerB,ServerC 中都是一樣的。
二、 GTID的工作原理：
1、master更新數據時，會在事務前產生GTID，一同記錄到binlog日誌中。
2、slave端的i/o 線程將變更的binlog，寫入到本地的relay log中。
4、如果有記錄，說明該GTID的事務已經執行，slave會忽略。
5、如果沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog。
6、在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描。
三、 GTID的優點：
1.一個事務對應一個唯一ID，一個GTID在一個服務器上只會執行一次
2.GTID是用來代替傳統復制的方法，GTID復制與普通復制模式的最大不同就是不需要指定二進制文件名和位置
3.減少手工幹預和降低服務故障時間，當主機掛了之後通過軟件從眾多的備機中提升一臺備機為主機
那麽GTID復制是怎麽實現自動同步，自動對應位置的呢？
例如：ServerC <-----ServerA ----> ServerB
主機ServerA
備機:ServerB,ServerC
當主機ServerA 掛了之後 ，此時ServerB執行完了所有從ServerA 傳過來的事務，
ServerC 延時一點。這個時候需要把 ServerB 提升為主機 ，Server C 繼續為備機。
當ServerC 鏈接ServerC 之後,首先在自己的二進制文件中找到從ServerA 傳過來的最新的GTID，
然後將這個GTID 發送到ServerB ,ServerB 獲得這個GTID之後,就開始從這個GTID的下一個GTID
開始發送事務給ServerC。這種自我尋找復制位置的模式減少事務丟失的可能性以及故障恢復的時間。
四、 GTID的限制：
1.不支持非事務引擎
2.不支持create table ... select 語句復制(主庫直接報錯)
原理：（ 會生成兩個sql，一個是DDL創建表SQL，一個是insert into 插入數據的sql。
由於DDL會導致自動提交，所以這個sql至少需要兩個GTID，但是GTID模式下，只能給這個sql生成一個GTID ）
3.不允許一個SQL同時更新一個事務引擎表和非事務引擎表
4.在一個復制組中，必須要求統一開啟GTID或者是關閉GTID
5.開啟GTID需要重啟（5.7除外）
6.開啟GTID後，就不再使用原來的傳統復制方式
7.對於create temporary table 和 drop temporary table語句不支持
8.不支持sql_slave_skip_counter
mysql之 MySQL 主從基於 GTID 復制原理概述