淺析mysql主從復制中的gtid

gtid(Global Transaction ID)是對于一個已提交事務的編號，并且是一個全局唯一的編號。它的官方定義如下：
gtid= source_id ：transaction_id

每一個 gtid代表一個數據庫事務。在上面的定義中，source_id 表示執行事務的主庫 uuid（server_uuid），transaction_id 是一個從 1 開始的自增計數，表示在這個主庫上執行的第 n 個事務。MySQL 只要保證每臺數據庫的 server_uuid 全局唯一，以及每臺數據庫生成的 transaction_id 自身唯一，就能保證 gtid 的全局唯一性。
在開啟gtid的主從復制的環境下，在slave上執行show slave status\G 可以看到下述信息：

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
...
           Retrieved_Gtid_Set: b5e3d908-fa6d-11e7-b931-06f990000100:1-3
            Executed_Gtid_Set: b5e3d908-fa6d-11e7-b931-06f990000100:1-3
                Auto_Position: 1
1 row in set (0.00 sec)

Retrieved_Gtid_Set 表示slave從master接受的gtid set，使用 reset slave 命令可以清空此項；
Executed_Gtid_Set 表示slave已執行的gtid set，使用 reset master 命令可以清空此項。
Retrieved_Gtid_Set 和 Executed_Gtid_Set 必須為master 上 gtid set 的子集，否則會報以下錯誤：

mysql> show slave status\G
*************************** 1. row ***************************
...
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'
...
1 row in set (0.00 sec)

slave 停掉后再次啟動時，會進行以下操作：
1.讀取master上的gtid set（假設為set A）
2.將set A和自身的 Retrieved_Gtid_Set（假設為set B） 對比，執行 A-B 部分的事務以保持和master的同步。

這里本來是要貼上驗證的操作的，但51cto博客的表格展示很不友好，所以驗證的工作就交給大家啦~^o^