1.基於gtid的主從複製的基礎知識
1.在傳統的複製裏面，當發生故障，需要主從切換，需要找到binlog和pos點，然後將主節點指向新的主節點，相對來說比較麻煩，也容易出錯。
2.基於GTID則不用再找binlog和pos點，我們只需要知道主節點的ip，端口，以及賬號密碼就行。
3.和基於position的主從複製的不同之處在於：它是以一整個事件爲單位進行復制的，pos是局部的複製，所以
（1）如果是基於position的主從複製：將一個事件拆開來複制，如果一個事件進行的過程中出現問題，那麼複製也會出現問題
（2）如果是基於gtid的主從複製：一個以事件爲單位進行復制，如果一個事件進行的過程中出現問題，那麼複製也不會出現問題
4.開啓GTID，無需找到binlog和POS點，直接change master to master_auto_postion=1即可，它會自動尋找同步
5.通過GDIT保證每個主庫上提交的事務在集羣中有一個唯一的ID.這種方式強化了數據庫的主備一致性，故障恢復以及容錯能力。
2.基於GTID複製實現的工作原理：
**
什麼是GTID：
GTID實際上是由UUID+TID (即transactionId)組成的。其中UUID(即server_uuid) 產生於auto.conf文件(cat /data/mysql/data/auto.cnf)，是一個MySQL實例的唯一標識。TID代表了該實例上已經提交的事務數量，並且隨着事務提交單調遞增，所以GTID能夠保證每個MySQL實例事務的執行（不會重複執行同一個事務，並且會補全沒有執行的事務）。**
GTID在一組複製中，全局唯一。通過GDIT保證每個主庫上提交的事務在集羣中有一個唯一的ID.這種方式強化了數據庫的主備一致性，故障恢復以及容錯能力。
** 步驟
1. 主節點更新數據時，會在事務前產生GTID，一起記錄到binlog日誌中。
2.從節點的I/O線程將變更的bin log，寫入到本地的relay log中。
3.SQL線程從relay log中獲取GTID，然後對比本地binlog是否有記錄（所以MySQL從節點必須要開啓binary log）。如果有記錄，說明該GTID的事務已經執行，從節點會忽略。如果沒有記錄，從節點就會從relay log中執行該GTID的事務，並記錄到bin log。**
3.實驗
這個是基於上個position的環境做的
由官網可知，要先去修改配置文件
/etc/my.cnf加入
加入：開啓gtid的信息
gtid_mode=ON
enforce-gtid-consistency=true
重啓數據庫
可以在mysql表裏面找到GTID
看看server1的uuid
修改server2的配置文件
和server2一樣
重啓server2的數據庫
mysql -uroot -pGaojia+123
show databases;
stop slave;
change master to master_host='172.25.62.1',master_user='repl',master_password='Gaojia+123',master_auto_position=1;從第一件事情開始跟蹤
start slave;
show slave status\G；
停止從複製，之後設置GTID複製
現在沒有插入數據時Gtid_set的參數後面沒有
server1上插入數據
後面就有參數了
server2上也有gtid_excuted插件
可以看見server2裏面gtid_excuted與之前看的server1的uuid相同
