GTID簡介

什么是GTID

GTID(Global Transaction ID)是對于一個已提交事務的編號，并且是一個全局唯一的編號。

GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標識。TID代表了該實例上已經提交的事務數量，并且隨著事務提交單調遞增。下面是一個GTID的具體形式

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

更詳細的介紹可以參見：官方文檔

GTID的作用

那么GTID功能的目的是什么呢？具體歸納主要有以下兩點：

根據GTID可以知道事務最初是在哪個實例上提交的GTID的存在方便了Replication的Failover 這里詳細解釋下第二點。我們可以看下在MySQL 5.6的GTID出現以前replication failover的操作過程。假設我們有一個如下圖的環境

此時，Server A的服務器宕機，需要將業務切換到Server B上。同時，我們又需要將Server C的復制源改成Server B。復制源修改的命令語法很簡單即CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn。而難點在于，由于同一個事務在每臺機器上所在的binlog名字和位置都不一樣，那么怎么找到Server C當前同步停止點，對應Server B的master_log_file和master_log_pos是什么的時候就成為了難題。這也就是為什么M-S復制集群需要使用MMM,MHA這樣的額外管理工具的一個重要原因。

這個問題在5.6的GTID出現后，就顯得非常的簡單。由于同一事務的GTID在所有節點上的值一致，那么根據Server C當前停止點的GTID就能唯一定位到Server B上的GTID。甚至由于MASTER_AUTO_POSITION功能的出現，我們都不需要知道GTID的具體值，直接使用CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION命令就可以直接完成failover的工作。 So easy不是么?

基于GTID的主從復制簡介

搭建

搭建使用了mysql_sandbox腳本為基礎，先創建了一個一主三從的基于位置復制的環境。然后通過配置修改，將整個架構專為基于GTID的復制。

根據MySQL官方文檔給出的GTID搭建建議。需要一次對主從節點做配置修改，并重啟服務。這樣的操作，顯然在production環境進行升級時是不可接受的。Facebook,Booking.com,Percona都對此通過patch做了優化，做到了更優雅的升級。具體的操作方式會在以后的博文當中介紹到。這里我們就按照官方文檔，進行一次實驗性的升級。

主要的升級步驟會有以下幾步：

確保主從同步在master上配置read_only，保證沒有新數據寫入修改master上的my.cnf，并重啟服務修改slave上的my.cnf，并重啟服務在slave上執行change master to并帶上master_auto_position=1啟用基于GTID的復制由于是實驗環境，read_only和服務重啟并無大礙。只要按照官方的GTID搭建建議做就能順利完成升級，這里就不贅述詳細過程了。下面列舉了一些在升級過程中容易遇到的錯誤。