如何進行MySQL主從GTID復制修復

如何進行MySQL主從GTID復制修復，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

GTID是5.6新增特性，減少DBA運維的工作。在以前一主兩從架構下當主庫M1發生故障我們需要選擇一個從庫S1作為新的主庫，但是S2要重新change master 到新主庫上 這時master_log_file和master_log_pos我們怎么獲取到呢？在沒有GTID時 MHA架構幫我們解決了這個問題，在有了GTID情況下，我們只需要在S2上面重新change master下設置MASTER_AUTO_POSITION = 1即可。 本文介紹下在GTID復制下遇到了錯誤如何解決。

場景描述

當我們使用GTID復制時，不能像傳統復制一樣跳過事務，只能注冊一個空的事務騙過MySQL。具體操作步驟如下:

查看當前備份的GTID執行情況

           Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-71462
            Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-71459,
e28420fb-f0be-11e5-af62-0050562edd64:1-81209
                Auto_Position: 0

Retrieved_Gtid_Set 代表已經接受到的GTID集合 
Executed_Gtid_Set 代碼已經執行的GTID集合

針對上面GTID執行情況 我們可以看到:

Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-71462
 Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-71459

接收到了71462 執行到了71459就報錯了。

手工注冊事務

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 12:59:41]>stop slave;
Query OK, 0 rows affected (0.00 sec)
[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:04:57]>set gtid_next='dd2a02a3-f0be-11e5-af62-0050563a97cc:71460';
Query OK, 0 rows affected (0.00 sec)
[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:23]>begin;
Query OK, 0 rows affected (0.00 sec)
[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:29]>commit;
Query OK, 0 rows affected (0.02 sec)
[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:31]>SET GTID_NEXT='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)
[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:36]>start slave;
Query OK, 0 rows affected (0.00 sec)

這里需要注意的是

set gtid_next='dd2a02a3-f0be-11e5-af62-0050563a97cc:71460'; 這個值是
Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-71459  71459這個GTID+1
并且 uuid一定是Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-71462 接收到這里顯示的uuid

再次查看show slave status\G 已經恢復正常

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:39]>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.10.30.101
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 28275288
               Relay_Log_File: mysql-relay-bin.000012
                Relay_Log_Pos: 21794
        Relay_Master_Log_File: mysql-bin.000003
             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:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 28275288
              Relay_Log_Space: 302335
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        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:
             Master_Server_Id: 101
                  Master_UUID: dd2a02a3-f0be-11e5-af62-0050563a97cc
             Master_Info_File: mysql.slave_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: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-72005
            Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-72005,
e28420fb-f0be-11e5-af62-0050562edd64:1-81209
                Auto_Position: 0

看完上述內容，你們掌握如何進行MySQL主從GTID復制修復的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！