Mysql基於GTIDs的複製

 

經過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