?

通過GTIDs【global transaction identifiers】,可以標識每一個事務，并且可以在其一旦提交追蹤并應用于任何一個Slave上；這樣 就不需要像BinaryLog復制依賴Log file 和位置。GTIDs完全基于事務，只要在Master提交的所有事務都在Slave上進行了Commit，那么就能保證Master和Slave之間的數據 一致性。你可以使用基于SBR或RBR的GTIDs來實現。推薦使用RBR【Row-based replication】.

　1 GTID介紹?

GTID的惟一性，不僅僅在Master上惟一，而是在整個集群中惟一。

GTID是由SourceId：transaction_Id 構成;SourceId用于標識源Server，即Master中的server_uuid[系統變量];transaction_id，是按照事務提交順序而生成的序列數字。如第一個被提交的是1，則其GTID=XXXXXXXXXXXX:1.

GTID被存儲于mysql.gtid_executed中，當gtid_mode=ON/ON_PERMISSIVE時。

GTID的生命周期

　　a.事務在Master上執行并提交

該事務用GTID標識，GTID由Master的UUID和一個非0的未被使用的事務序列號構成；該GTID被寫入Master的BinLog中。

　　b.之后BinLog被傳送到Slave上并存儲在Slave的relay Log中【using established mechanisms for this process】.Slave讀取到這個GTID，并為系統變量gtid_next賦值，這就告訴了Slave下一個要執行的事務【transaction】就是這個。

　　c.Slave確認該GTID是否已被使用【在其BinLog中】。若未用，則執行transaction并寫入BinLog。需要注意的是：不僅僅是檢查BinLog而且要確認沒有其他session 已讀取但未提交。換句話說，多個Clients不允許并行執行同一事務。

　　d.由于gtid_next不為空。Slave執行并寫入BinLog。

2.構建GTID復制

　　a. 同步數據。即將Master與Slave的數據同步到一致，然后都開啟SET @@global.read_only=ON;

　　b.停止Servers。可使用：mysqladmin -uroot -p shutdown

　　c.配置主從Server.確保雙方都開啟gtid_mode=ON，enforce_gtid_consistency=ON。

　　d.將Slave掛載到Master，告訴Slave將使用哪個Master作為復制的數據源。使用CHANGE MASTER TO語句，一定要啟用MASTER_AUTO_POSITION=1,告訴Slave事務將由GTIDS標識。

　　e.啟動Slave. START SLAVE.

　　f.關閉 read_only.?SET @@global.read_only = OFF.

3.使用GTIDs限制

　　GTIDs是基于事務的【transactions】,所以對非事務的操作不會支持。

?　　CREATE TABLE ... SELECT statements .creat table ...select對基于語句的復制【SBR】是不安全的。

　　Temporary tables 。GTIDsg不支持CREATE ?TEMPORARY TABLE AND DROP TEMPORARY TABLE .

　【Preventing execution of unsupported statements】阻止不支持語句的執行。為了防止GTID受到不支持語句的影響而失敗，在參與復制的Server上都要使用enforce-gtid-consistency操作。

　　sql_slave_skip_counter用于跳過不支持的事務【這在GTIDs不支持】。

　　在gtid_mode=ON時不要進行mysql_upgrade,因為Mysql_update會用MyiSam引擎改變一些系統表。

　　也不要在gtid_mode=ON時進行mysqldump文件的導入。

也可參考這篇文章：

http://www.cnblogs.com/abobo/p/4242417.html?

?

轉載于:https://www.cnblogs.com/itdev/p/6002713.html

總結

以上是生活随笔為你收集整理的Mysql基于GTIDs的复制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。