基於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，數據也有了~~~