MySQL5.6有很多新的特性，其中很多人都感興趣的一條就是全局事務序號功能（GTIDs）。而大家都對這一特性很感興趣的原因也很好理解，即：本來重新連接從服務器和一個新的主服務器一直是件很麻煩的事，然而在啟用GTIDs功能之後就變得簡單易行。可是，GTIDs的使用不單單是用單獨的標識符替換舊的二進制日志文件/位置，它也采用了新的復制協議。假如你還不太明白這些，那你可以在這篇文章裡學點什麼。
復制協議：新的 VS 舊的
舊的協議往往簡單直接即：首先從服務器上在一個特定的偏移量那裡連接到一個給定的二進制日志文件，然後主服務器在從那裡發送所有的事務。
新協議稍有不同：slave首先會發送它已經執行過的GTID的范圍，然後master發送每一個丟失的事務. 它也確保了一個給定的GTID只可以在一個特定的slave中執行一次.
實踐中，這會改變任何東西嗎? 使得，它會改變很多東西. 想象一下下面的場景: 你想要從trx 4開始復制，但是trx2在slave上因為某種緣故丟失了.
使用老協議的話，trx 2再也不會被執行一次，而使用新協議，它就會被自動的再執行一次.
下面是兩個你可以在實踐中看到新協議的通用場景.
跳過事務
眾所周知老的 SET GLOBAL sql_slave_skip_counter = N 在你想要跳過一個事務時不再提供支持，而GTID就可以被啟用了. 換用 GTID XXX:N 來跳過事務, 你須得 注入一個空的事務:
mysql> SET gtid_next = 'XXX:N'; mysql> BEGIN; COMMIT; mysql> SET gtid_next = 'AUTOMATIC';
為什麼我們不能使用 sql_slave_skip_counter? 就是因為新的復制協議!
想象一下我們擁有如下圖所示的三台服務器:
讓我們假設 sql_slave_skip_counter 可以用並且已經被用在S2上用於跳過trx2. 如果你吧S2設置成S1的一個slave將會發生什麼呢?
兩個服務器會互相交換被執行了GTID的范圍，並且S1將會意識到其必須將trx2發送給S2. 然後會發生的事情有兩種可能:
很明顯這不安全，這就是為什麼 sql_slave_skip_counter 在使用GTID時是不能用的. 要想跳過一個事務，唯一安全的選擇就是去執行一個虛擬的事務，而不是一個真實的事務.
錯誤的事務
如果你在一個slave上本地執行了一個事務 (在MySQL文檔中被稱為錯誤事務), 如果你被這個事務推送到新的master上時會發生什麼呢?
使用老協議，基本上沒啥事（准確點說，新的master和其slave之間的數據將會出現不一致，但那在稍後就可能會被修復）.
使用新協議，錯誤的事務將會被識別成為在每個地方都丟失了，並且將會自動在容錯備份上被執行，這樣就將會導致打斷復制的隱患.
比方說，你擁有一個master（M)和兩個slave (S1 和 S2). 這裡有兩種將slave重連到新的master將會發生（帶有不同復制錯誤的）失敗的場景:
# 場景 1
# S1
mysql> CREATE DATABASE mydb;
# M
mysql> CREATE DATABASE IF NOT EXISTS mydb;
# Thanks to 'IF NOT EXITS', replication doesn't break on S1. Now move S2 to S1:
# S2
mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;
# This creates a conflict with existing data!
mysql> SHOW SLAVE STATUS\G
[...]
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 'mydb'; database exists' on query. Default database: 'mydb'. Query: 'CREATE DATABASE mydb'
[...]
# 場景 2
# S1
mysql> CREATE DATABASE mydb;
# Now, we'll remove this transaction from the binary logs
# S1
mysql> FLUSH LOGS;
mysql> PURGE BINARY LOGS TO 'mysql-bin.000008';
# M
mysql> CREATE DATABASE IF NOT EXISTS mydb;
# S2
mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;
# The missing transaction is no longer available in the master's binary logs!
mysql> SHOW SLAVE STATUS\G
[...]
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
[...]
你可以這樣理解，錯誤的事務應該借助基於GTID的服務得以避免. 如果你需要運行一個本地事務，最好的選擇是針對那條特定的語句禁用二進制日志:
mysql> SET SQL_LOG_BIN = 0; mysql> # Run local transaction
結論
GTIDs在讓我們方便重新和其他服務器連接副本方面是個不小的進步。然而同樣的在運維方面我們也因此面臨新的困難和挑戰。假如你打算開始使用GTIDs,那麼你就得確實理解新的復制協議，否則你就會以一種想不到的方式結束復制過程。
