基於GTID的複製是從Mysql5.6開始支援的一種新的複製方式，此方式與傳統基於日誌的方式存在很大的差異，在原來的基於日誌的複製中，從伺服器連線到主伺服器並告訴主伺服器要從哪個二進位制日誌的偏移量開始執行增量同步，這時我們如果指定的日誌偏移量不對，這與可能造成主從資料的不一致，而基於GTID的複製會避免。
在基於GTID的複製中，首先從伺服器會告訴主伺服器已經在從伺服器執行完了哪些事務的GTID值，然後主庫會有把所有沒有在從庫上執行的事務，傳送到從庫上進行執行，並且使用GTID的複製可以保證同一個事務只在指定的從庫上執行一次，這樣可以避免由於偏移量的問題造成資料不一致。
什麼是GTID，也就是全域性事務ID，其保證為每一個在主上提交的事務在複製叢集中可以生成一個唯一的ID。
一個GITD由兩部分組成的，分別是source_id 和transaction_id，GTID=source_id:transaction_id，其中source_id就是執行事務的主庫的server-uuid值，server-uuid值是在mysql服務首次啟動生成的，儲存在資料庫的資料目錄中，在資料目錄中有一個auto.conf檔案，這個檔案儲存了server-uuid值（唯一的）。而事務ID則是從1開始自增的序列，表示這個事務是在主庫上執行的第幾個事務，Mysql會保證這個事務和GTID是一比一的關係。
配置主資料庫伺服器需要做的大概和傳統的主從配置差不多，需要起碼的在主伺服器上建立複製賬號，還要配置資料庫日誌檔案的目錄，這是必須的啟動bin_log日誌。
可以指定bin_log存放目錄，而不是用資料目錄，分開儲存是個好習慣，特別是如果把日誌和資料放在不同的磁碟分割槽上，這樣不但可以避免日誌的增長把資料磁碟分割槽佔滿，也可以提高了磁碟IO。如bin_log = /usr/local/mysql/log/mysql-bin。
優點
A：很方便的進行故障轉移，因為GTID是全域性唯一的識別符號，所以就很簡單知道哪些事務在從伺服器沒有執行，在多個從伺服器也沒必要進行多個日誌偏移量配置了.
B：從庫和主庫的資料一致性。
缺點
A:故障處理比日誌處理複雜。
B:執行語句的一些限制。
開始配置GTID主從複製
虛擬機器IP：192.168.136.142（Master）、192.168.136.143（Slave）
Mysql版本：5.6（5.7的配置與5.6稍微有些不一樣，如果你的Mysql版本是5.7，可以參考其他文章）
首先配置一下主伺服器，編輯/etc/my.cnf
[mysqld]
port = 3306
socket = /tmp/mysql.sock
basedir = /usr/local/mysql
datadir = /data/mysql
pid-file = /data/mysql/mysql.pid
server-id = 142
log_bin = mysql-bin
bin_log = /usr/local/mysql/log/mysql-bin
binlog_format = ROW //建議row
log-slave-updates=true //在從伺服器進入主伺服器傳入過來的修改日誌所使用，在Mysql5.7之前主從架構上使用gtid模式的話，必須使用此選項，在Mysql5.7取消了，會增加系統負載。
enforce-gtid-consistency=true // 強制gtid一直性，用於保證啟動gitd後事務的安全；
gtid-mode=on //開啟gtid模式
master_info_repository=TABLE
relay_log_info_repository=TABLE //指定中繼日誌的儲存方式，預設是檔案，這樣配置是使用了 兩個表，是INNODB儲存引擎，好處是當出現資料庫崩潰時，利用INNODE事務引擎的特點，對這兩個表進行恢復，以保證從伺服器可以從正確位置恢復資料。
sync-master-info=1 //同步master_info,任何事物提交以後都必須要把事務提交以後的二進位制日誌事件的位置對應的檔名稱，記錄到master_info中，下次啟動自動讀取，保證資料無丟失
slave-parallel-workers=2 //設定從伺服器的啟動執行緒數，0表示不啟動
binlog-checksum=CRC32 //主服務端在啟動的時候要不要校驗bin-log本身的校驗碼
master-verify-checksum=1 //都是在伺服器出現故障情況下，讀取對伺服器有用的資料
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1 //啟用後，可用於在二進位制日誌記錄事件相關資訊，可降低故障排除複雜度（並非強制啟動）
report-port=3306
report-host=192.168.136.142
配置完成之後別忘了重啟Mysql。
檢視一下master狀態，多了一項。
主服務進入Mysql，命令列執行授權
grant replication client,replication slave on *.* to root@'192.168.136.%' identified by 'root123'; //ip段與賬號密碼
flush privileges; //重新整理許可權
show grants for root@'192.168.136.%';
啟動配置之前，我們同樣需要對從伺服器進行初始化。對從伺服器初始化的方法基本和基於日誌點是相同的，只不過在啟動了GTID模式後，在備份中所記錄的就不是備份時的二進位制日誌檔名和偏移量了，而是記錄的是備份時最後的GTID值。
檢視一下有哪些資料庫，退出Mysql終端，進入一個目錄，把目標庫備份一下，這裡是testdb
mysqldump --single-transaction --master-data=2 --triggers --routines --database testdb -uroot -p > testdb.sql
備份完成之後，檢視一下sql檔案內容。
然後把當前sql檔案拷貝到從伺服器，這裡使用scp命令。
scp -P22 testdb.sql root@192.168.136.143:/data/mysql/
拷貝完之後，進入從伺服器Mysql終端，建立目標資料庫，然後倒入到從庫。
mysql -uroot -p testdb < testdb.sql
倒入成功之後，接下來配置從伺服器，與主伺服器配置大概一致，從伺服器可以在配置檔案裡面新增 read_only＝ON ,使從伺服器只能進行讀取操作，此引數對超級使用者無效，並且不會影響從伺服器的複製；
port = 3306
socket = /tmp/mysql.sock
basedir = /usr/local/mysql
datadir = /data/mysql
pid-file = /data/mysql/mysql.pid
user = mysql
bind-address = 0.0.0.0
server-id = 143
log_bin = mysql-bin
bin_log = /usr/local/mysql/log/mysql-bin
binlog_format = ROW //建議row
log-slave-updates=true
enforce-gtid-consistency=true
gtid-mode=on
master_info_repository=TABLE
relay_log_info_repository=TABLE //指定中繼日誌的儲存方式，預設是檔案，這樣配置是使用了 兩個表，是INNODB儲存引擎，好處是當出現資料庫崩潰時，利用INNODE事務引擎的特點，對這兩個表進行恢復，以保證從伺服器可以從正確位置恢復資料。
sync-master-info=1
slave-parallel-workers=2 //開啟執行緒數，0就表示禁用執行緒
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
report-port=3306
report-host=192.168.136.143
read_only = on //這個引數主要保證從伺服器的資料安全性
別忘了重啟mysql。
然後進入mysql終端，使用change master 配置主從
change master to master_host='192.168.136.142',master_user='root',master_passwrd='root123',master_auto_position=1;
start slave; //配置完成啟動slave
在主資料庫端檢視一下
配置成功了。然後試著在主庫上執行一條insert 語句，在從庫上檢視，OK，資料也有了~~~