首先看一下什么是GTID：
GTID(Global Transaction ID)是對於一個已提交事務的編號，並且是一個全局唯一的編號。
GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標識。TID代表了該實例上已經提交的事務數量，並且隨着事務提交單調遞增。根據GTID可以知道事務最初是在哪個實例上提交的，而且方便故障切換。
接下來就看一下怎么在GTID模式下快速的添加一個slave：
我們知道在沒有GTID復制以前，MySQL的復制是基於binary log和position來做的，之前的復制我們要執行下面的change語句：
CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='*****',MASTER_LOG_FILE='mysqlbinlog.000003',MASTER_LOG_POS=99721204;
而我們在GTID就可以執行以下的change語句：
CHANGE MASTER TO MASTER_HOST='****', MASTER_USER='repl', MASTER_PASSWORD='******', MASTER_PORT=3306, master_auto_position=1;
我們可以看到，基本上來說指定復制的時候原來的binary log方式需要指定MASTER_LOG_FILE和MASTER_LOG_POS，而GTID復制卻不需要知道這些參數。
下面看一下怎么在GTID的模式下創建主從復制：
從上面可以看得到，在GTID的模式下我們不再需要知道MASTER_LOG_FILE和MASTER_LOG_POS兩個參數，相比之下我們只需要指定master就可以了，這對於創建復制來說簡單的多了。在GTID的模式下我們需要知道以下兩個全局變量：
root@perconatest09:23:44>show global variables like 'GTID_%'\G *************************** 1. row *************************** Variable_name: gtid_executed Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24 *************************** 2. row *************************** Variable_name: gtid_executed_compression_period Value: 1000 *************************** 3. row *************************** Variable_name: gtid_mode Value: ON *************************** 4. row *************************** Variable_name: gtid_owned Value: *************************** 5. row *************************** Variable_name: gtid_purged Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-12
我們主要需要看到的就是gtid_executed和gtid_purged兩個參數，
gtid_executed：這個是已經執行過的所有的事物的GTID的一個系列串，也就是binary log里面已經落盤的事物的序列號。這個參數是只讀的，不能夠進行設置。
gtid_purged：這個序列是指我們在binary log刪除的事物的GTID的序列號。我們可以手動進行設置，方便我們做一些管理。
這兩個參數理解以后，接下來我們看一下怎樣去添加一個GTID復制的從庫：
（1）：從主庫做一個全備份，而且要記錄主庫備份時間點的gtid_executed
（2）：從庫進行恢復，而且將從庫的gtid_purged設置為我們第一步獲取的master的gtid_executed
（3）：執行CHANGE MASTER 語句。
我們使用mysqldump就可以將主庫進行備份，並且將備份還原到一台新的機器作為從庫。在執行之前先在主庫看一下參數：
root@perconatest09:23:58>show global variables like 'GTID_e%'\G *************************** 1. row *************************** Variable_name: gtid_executed Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24 2 rows in set (0.01 sec) root@perconatest09:41:33>show global variables like 'GTID_p%'\G *************************** 1. row *************************** Variable_name: gtid_purged Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-12 1 row in set (0.01 sec)
然后在主庫進行備份：
mysqldump -uroot -p --set-gtid-purged=off --single-transaction --triggers --routines --all-databases> /home/sa/backup.sql
我們可以看一下備份文件：
[root@localhost sa]# head -30 backup.sql
我們能夠看到有以下的參數：
SET @@GLOBAL.GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
也就是說當我們進行恢復的時候，是會自動設置GTID_PURGED的，而這個值剛好就是master的gtid_executed，所以我們從庫恢復以后基本上就不需要在做指定了。
進入從庫恢復數據：
source backup.sql;
我們知道已經不需要在指定GTID_PURGE的值了，要是不確定還可以確認一下：
show global variables like 'gtid_executed'; show global variables like 'gtid_purged';
后面直接指定復制就好了：
CHANGE MASTER TO MASTER_HOST="***", MASTER_USER="root", MASTER_PASSWORD="*****", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;
將*替換為你需要指定的主庫的相關信息就OK了。
GTID主從復制的模式下如果出現錯誤，我們該怎么恢復呢？
假如我們的主庫的日志已經purged，執行了reset等操作，我們從庫會有如下報錯：
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
提示我們找不到日志，主從復制就會停掉，下面我們看一下處理方式：
（1）主庫執行以下操作：
root@perconatest09:41:38>show global variables like 'GTID_EXECUTED'; +---------------+---------------------------------------------------------------------------------------------------------------------------------+ | Variable_name | Value | +---------------+---------------------------------------------------------------------------------------------------------------------------------+ | gtid_executed | 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24 | +---------------+---------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.01 sec)
（2）從庫
root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
注意，在指定前首先要確認這個值是空的，不然我們要做以下操作：
root@(none)03:04:49>reset master; root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24'; root@(none)03:04:49>start slave; root@(none)03:04:49>show slave status\G
這樣修復就完成了，但是我們最好還是用checksum校驗一下主從數據的一致性。
報錯信息：
Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires
（貼個錯誤信息為了增加瀏覽量）
當然上面的方法並不能保證數據的完全一致性，我們還要去校驗使用 pt-table-checksum and pt-table-sync，但是這樣效率不一定是最高的，最好的方式還是通過前面介紹的，做全備份，然后恢復，再指定master，這才是最靠譜的。