MySQL 5.6版本GTID復制異常處理一例

昨天處理了一個MySQL 5.6版本下開啟GTID模式復制異常案例，MASTER上的任何操作都無法在SLAVE上應用，SLAVE的RELAY LOG里有記錄，但SLAVE的BINLOG卻找不到蛛絲馬跡。由于開啟了GTID，所以排查起來也簡單，只需要在SLAVE上把RELAY LOG和BINLOG分別解析成文本文件，再直接搜索MASTER的UUID，就能找到SLAVE上是否應用了MASTER復制過來的事務。 排查過程中，曾經(jīng)一度懷疑是因為設置了BINLOG-DO或者IGNORE規(guī)則，或者設置了REPLICATION-DO或IGNORE規(guī)則，甚至是GTID的嚴重BUG，但都沒發(fā)現(xiàn)端倪。直到從 SHOW SLAVE STATUS 里發(fā)現(xiàn)下面這個信息：

[yejr@imysql.com]> show slave status\G
*************************** 1\. row ***************************
               Slave_IO_State: Waiting for master to send event
...
 Master_Log_File: mysql-bin.000001
 Read_Master_Log_Pos: 2539
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 1996
 Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
# 兩個線程工作正常
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
#沒設置任何規(guī)則
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
 Exec_Master_Log_Pos: 2539 # 無論binlog file 還是 pos，都和MASTER保持一致，也就是說BINLOG的接收和RELAYR LOG的APPLY都很正常，有條不紊工作著
              Relay_Log_Space: 2778
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
...
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
# 沒設置忽略某些 server-id 上的BINLOG
             Master_Server_Id: 123315
                  Master_UUID: 35cc99c6-0297-11e4-9916-782bcb2c9453
             Master_Info_File: /data/db11_3316/master.info
 SQL_Delay: 0 # 沒有設置復制延遲策略          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 4294967295
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451
 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929                Auto_Position: 1

從上面的日志發(fā)現(xiàn)什么了沒？尤其是這兩行：

           Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451
 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929                Auto_Position: 1

這下有點明白了吧，意思是：

1、SLAVE從MASTER上復制了GTID范圍是：1-451；
2、SLAVE上執(zhí)行GTID的范圍分為兩段，一段是：1-2455，另一段是：792490-4517929；

尼瑪，不應該是連續(xù)的嘛，怎么會這么奇葩⊙﹏⊙b，這可如何是好呀，好捉急~~~ 莫急，且容我們慢慢分析為啥GTID從MASTER到SLAVE之后發(fā)生了斷點，產(chǎn)生了間隙。

正常滴，在MySQL 5.6啟用GTID后，部署REPLICATION復制時，可以設定 MASTER_AUTO_POSITION = 1，讓 SLAVE 根據(jù) GTID 自動選擇適當?shù)氖聞拯c進行復制，DBA基本上無需關注和擔心主從不一致的問題，還是很讓DBA省心的。 在啟用 MASTER_AUTO_POSITION = 1 的情況下，正常是不會發(fā)生 GTID 中間有個空隙，產(chǎn)生斷點的問題發(fā)生。除非是下面這種情況：

1、人工暫停SLAVE進程；
2、MASTER上繼續(xù)寫入數(shù)據(jù)；
3、MASTER上刷新LOG；
4、MASTER上刪除舊BINLOG，只保留最新的BINLOG；
5、SLAVE上啟動MASTER，這時候會報錯，像下面這樣：
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.'

針對這種問題的處理方法可以這么做：

1、關閉MASTER_AUTO_POSITION，即設置 MASTER_AUTO_POSITION = 0；
2、手工CHANGE BINLOG FILE & POS；

這種情況下，不能再次設置 MASTER_AUTO_POSITION = 1，否則還會再次報錯。 還有一種情況會發(fā)生 GTID 間隙斷點問題，例如這樣：

1、正常配置 REPLICATION 復制，但是設置 MASTER_AUTO_POSITION = 0，也就是人工指定 BINLOG FILE & POS的傳統(tǒng)方法；
2、在復制過程中，暫時關閉 SLAVE 進程；
3、手工修改 BINLOG FILE & POS 信息，指向新的 BINLOG FILE & POS 點；
4、啟動SLAVE，這時候就會發(fā)現(xiàn) GTID 斷點的現(xiàn)象重現(xiàn)了；

在主從高可用模式下，可能主從間會發(fā)生切換，然后再次切換回來，這時候也可能發(fā)生上述的斷點問題。因此我們建議采用雙主來部署高可用切換，基本上可以實現(xiàn)任意來回切換，無需手工指定新的 BINLOG FIEE & POS 信息。

還有最后一種情況，就是在 MASTER 上執(zhí)行了 RESET MASTER，導致 MASTER 上的 BINLOG FILE & POS 全部重置，SLAVE 上讀取到的信息自然也就不一致了。

好了，說了那么多，我們最后來說下如何應對處理 GTID 斷點的問題。

方法一：手工修改 BINLOG FILE & POS

1、關閉SLAVE；
2、手工CHANGE BINLOG FILE & POS，指向MASTER上最新產(chǎn)生的BINLOG FILE & POS，并且設置 MASTER_AUTO_POSITION = 0；
3、啟動SLAVE;

方法二：手工修改 GTID_PURGED 值

1、關閉 SLAVE；
2、在 SLAVE 上執(zhí)行 RESET MASTER，重設 SLAVE 上的 BINLOG FILE & POS（如果這個節(jié)點用于復制中繼，要注意所有binlog是否都被讀取完畢，避免數(shù)據(jù)丟失）；
3、在 SLAVE 上執(zhí)行 SET @@GLOBAL.GTID_PURGED = '35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455';
4、啟動 SLAVE；

這種做法比較費解一點，意思是，我們告訴SLAVE要主動拋棄掉 MASTER 上傳輸過來的某些區(qū)間的事務。在這個例子中，我們拋棄了 1-2455 這個區(qū)間，也就是在 GTID 從 2466 開始，又會繼續(xù)應用 RELAY LOG 了，相比我們最開始的那個信息：

           Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451
 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929

我們強制 SLAVE 只忽略 1-2455 這個區(qū)間，從 2466 開始繼續(xù)復制，消除了本來也會被忽略的區(qū)間： 792490-4517929，確保新產(chǎn)生的事務都會被繼續(xù)應用。這個做法可以參考MySQL手冊：Excluding transactions with gtid_purged。

還有另外一種費力不討好的做法，就是在 MASTER 上執(zhí)行一些沒用的空事務，使得 GTID 的序號一直在加大，直到超過 2555 為止，然后在 792490-4517929 這個區(qū)間依法炮制一番，但我們非常不推薦采用這種做法，既麻煩又容易誤操作。 說了這么多，在 MySQL 5.6及以上版本中，我們強烈建議啟用 MASTER_AUTO_POSITION = 1，讓 MySQL 自己去做判斷，減少一些不必要的問題，并且采用雙主（其中一個主設為只讀）的方式，方便兩個主之間可以隨意相互切換，而不必擔心數(shù)據(jù)不一致。

上面過程我采用的MySQL版本：5.6.17-65.0-rel65.0-log Percona Server with XtraDB (GPL), Release rel65.0, Revision 587，實際案例發(fā)生的MySQL版本當時忘了記錄了，但肯定也是5.6以上的啦，哈哈~~~