處理 MySQL 因為 SLAVE 崩潰導致需要手動跳過 GTID 的問題 | 關於 GTID

今天發生了與之前某篇博客相似的問題，有同學在不同步的 binlog 庫中使用語句 database.table 命令對表進行 drop 導致 master 丟棄該表但是從庫並未能同步到該操作。並且后續又實用 use xxxx 對該表進行增刪字段，由於salve 並未建立此表於是 slave 崩潰的情況。

slave 崩潰信息通過查看 MySQL 錯誤日志差不多是這樣

2019-07-11 15:05:12 17674 [ERROR] Slave SQL: Error 'Table 'api.ring_king_record' doesn't exist' on query. Default database: 'api'. Query: 'ALTER TABLE `api`.`ring_king_record`
CHANGE COLUMN `course_id` `course_id` VARCHAR(45) NULL DEFAULT '' AFTER `id`,
CHANGE COLUMN `title` `title` VARCHAR(45) NULL DEFAULT '' AFTER `course_id`,
CHANGE COLUMN `serialNumber` `serial_number` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '唯一標示碼' ,
CHANGE COLUMN `tsaCount` `tsa_count` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '剩余確權次數'', Error_code: 1146
2019-07-11 15:05:12 17674 [Warning] Slave: Table 'api.ring_king_record' doesn't exist Error_code: 1146
2019-07-11 15:05:12 17674 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000762' position 16412436.
2019-07-11 15:05:12 17674 [Note] Slave I/O thread: connected to master 'xxxx',replication started in log 'mysql-bin.000763' at position 2157463

可以很清晰的看到錯誤的原因是 api.ring_king_record 這個表根本不存在，但是卻嘗試去操作 change column 的操作。所以 slave 直接崩潰了， MySQL 提示我們數據庫已經停止同步希望我們修復了這個問題之后再使用 SLAVE START 來啟動 slave 的同步跟上 master.

 

這里只需要關注兩個地方

1. mysql-bin.000762 可以讓我們定位到發生問題是哪個 binlog。

2. position 可以讓我們定位到發生的位置是在哪兒。

 

通過 position 16412435 如果你可以訪問 master 物理機，那么可以通過訪問 binlog 所在目錄使用命令

mysqlbinlog mysql-bin.000672 | grep -C 100 16412435

去查看相關的信息，包括前后是什么語句，之類的。

 

如果類似於使用了 rds 這樣的 MySQL 服務，可以去 master 所在的 rds 並使用 MySQL Client 上執行語句

show binlog events in 'mysql-bin.000762' from 16412436 limit 10\G;

 

我們可以得到從崩潰該語句開始的一些信息

mysql> show binlog events in 'mysql-bin.000762' from 16412436 limit 10\G;
*************************** 1. row ***************************
   Log_name: mysql-bin.000762
        Pos: 16412436
 Event_type: Gtid
  Server_id: 1215612563
End_log_pos: 16412484
       Info: SET @@SESSION.GTID_NEXT= '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038123'
*************************** 2. row ***************************
   Log_name: mysql-bin.000762
        Pos: 16412484
 Event_type: Query
  Server_id: 1215612563
End_log_pos: 16412989
       Info: use `api`; ALTER TABLE `api`.`ring_king_record`
CHANGE COLUMN `course_id` `course_id` VARCHAR(45) NULL DEFAULT '' AFTER `id`,
CHANGE COLUMN `title` `title` VARCHAR(45) NULL DEFAULT '' AFTER `course_id`,
CHANGE COLUMN `serialNumber` `serial_number` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '唯一標示碼' ,
CHANGE COLUMN `tsaCount` `tsa_count` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '剩余確權次數'
*************************** 3. row ***************************
   Log_name: mysql-bin.000762
        Pos: 16412989
 Event_type: Gtid
  Server_id: 1215612563
End_log_pos: 16413037
       Info: SET @@SESSION.GTID_NEXT= '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038124'
*************************** 4. row ***************************
   Log_name: mysql-bin.000762
        Pos: 16413037
 Event_type: Query
  Server_id: 1215612563
End_log_pos: 16413277
       Info: /* rds internal mark */ CREATE TABLE IF NOT EXISTS mysql.ha_health_check (
  id   BIGINT  DEFAULT 0,
  type CHAR(1) DEFAULT '0',
  PRIMARY KEY (type)

這里可以很清楚的看到崩潰位置 16412436 GTID: 8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038123 執行了 change column 的操作導致了崩潰。

現在我們要恢復 slave 就需要跳過這個報錯的語句。因為全局開啟了 GTID 的關系我們無法使用傳統的

root@(none) >stop slave;
Query OK, 0 rows affected (0.00 sec)

root@(none) >SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N;    #跳過N個事務
Query OK, 0 rows affected (0.00 sec)

root@(none) >start slave;
Query OK, 0 rows affected, 1 warning (0.03 sec)

來恢復 會報錯
ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

 

我在網上查了不少資料，但是感覺大部分都是互相 copy xjb 扯淡，也根本使用不了。

下面是我結合幾個靠譜博客和官方文檔寫的一個配置

stop slave;
reset master;
reset slave;
CHANGE MASTER TO MASTER_HOST='master_address',MASTER_USER='xxx', MASTER_PASSWORD='xxx';
set global gtid_purged = '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038123'; 
SET @@SESSION.GTID_NEXT= '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038124'; 
begin; 
commit; 
SET GTID_NEXT="AUTOMATIC"; 
start slave;

下面我會依次介紹這些命令是用來干嘛的。

首先我們所有現在針對去恢復的 slave 操作都需要先停止 slave.

reset master 這一步我不是很確定是否真的可以不做，reset master 會將 slave 機器的所有 binlog 都清空。比如之前我們可能是 mysql-bin.000023 這樣子，如果使用了 reset master 會重新從 mysql-bin.000001 開始記錄 binlog。我因為清理了也沒關系，因為我會要顯示的指定我從 master 機器的什么位置開始消費並且追上 master 所以就設置了。

reset slave 將讓 slave 忘記主從復制的關系的位置信息，它會刪除 master.info 和 relay-log.iinfo 文件重置 relaylog 信息。我們知道 relay-log 其實就是用於記錄 slave 復制 master 信息復制到哪里來了這里會重置這些信息。

然后我哦們指定 change master 重新指定我們要跟隨的 master 地址。

設置全局的 gtid_purged 這里注意 這個 gtid_purged 用於告訴你的 slave 無視哪些 gtid 的記錄段，就是我們會無視掉所有之前我們消費過的記錄段直到到達我們報錯的位置。這個可以跟下面的參數聯動。從上面的圖我們看到我們只需要跳過 change column 那條語句所在的 GTID 重新從 

8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038124 

開始消費即可跳過，所以上面我們使用 30038124-1 來表示我們需要 purged 的部分。

最后我們通過提交一個空事務並指定自動位移 GTID 來恢復我們的 slave。

一切完成之后我們啟動 slave 使用 start slave 

 

這個時候我們的 slave 從庫會從我們指定的位置開始追上 master 只需要等待一段時間即可，那么如何判斷已經追上了 master 呢？

我們在從庫上執行
show slave status

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: xxxxxxxxxxxx
                  Master_User: xxxx
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000764
          Read_Master_Log_Pos: 6362259
               Relay_Log_File: mysqld-relay-bin.000006
                Relay_Log_Pos: 6362469
        Relay_Master_Log_File: mysql-bin.000764
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxxxxxxxxxxx
          Replicate_Ignore_DB: mysql
           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: 6362259
              Relay_Log_Space: 6362761
              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: 1215612563
                  Master_UUID: 8dcfd361-10cb-11e9-9060-506b4b2ac23e
             Master_Info_File: /var/lib/mysql/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: 8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038448-30142673
            Executed_Gtid_Set: 0cf0e744-f9f6-11e8-bb7a-00163e302177:1-27887,
8dcfd361-10cb-11e9-9060-506b4b2ac23e:1-30142673
                Auto_Position: 1

比較 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 差不多就說明已經追上了 master。

Relay_Log_Pos 和他們差不多能說明 io 線程也能拉到最新的數據。

 

當我們有錯誤的時候 show slave status 也可以給我們提供非常多的信息，例如最后出錯的信息是啥。為什么報錯都有顯示，如果沒有第一時間去看錯誤日志，使用命令在這里看錯誤信息也不錯。

另外使用 show variables like '%gtid%'; 也可以給我們提供一些基於 gtid 的信息。

唔。。。又是修數據跑監控的一天=。=

 

---------------------------------分割線---------------------------------

關於 GTID 昨晚回去 我重新翻看了一些資料覺得還是有必要多說兩句。

可以說 GTID 的出現解決了之前完全依賴 master 文件和 pos 的來切換主從的問題得到了解決。

MySQL 版本5.6 引入了 GTID 解決主從同步位點問題。GTID 的全稱是 Global Transaction Identifier 也就是全局事務 ID,是一個事務在提交的時候生成的，是這個事務的唯一標識。它由兩部分組成：

GTID=server_uuid:gno

其中 server_uuid 是一個實例第一次啟動時自動生成的，可以通過我們上面介紹的命令 show master/slave status 看到該機器的 UUID

gno 是一個整數，初始化是1，每次提交事務的時候分配給這個事務，並加 1。

GTIO 模式的啟動配置：

#GTID
gtid_mode=on
enforce_gtid_consistency=on
log-slave-updates=1

GTID_mode 開啟的參數相關的是前兩個參數， log-slave-updates = 1 是開啟連貫復制 log

本身 slave 同步 master 的日志是不會再放入自己的 binlog 中的，如果我們還有機器在監聽 slave 的 binlog 日志就需要開啟 log-slave-updates 參數。

在 GTID 模式下，每個事務都會跟一個 GTID 一一對應。這個 GTID 有兩種生成方式，而使用哪種取決於 session 變量 gtid_next 的值。

 

可以看到上面我們在跳過事務的時候是直接指定了一個 GTID_NEXT 的位置從這個位置開始。

然后指定下面的偏移規則是 gtid_next=automatic 使用默認值每執行一個事務就 +1

 

這樣每個 MySQL 實例都維護了一個 GTID 集合，用來對應“這個實例執行過的所有事務”。

因為這個集合的存在，所以我們在重制  slave 和 master 的進度的時候，如果 slave 並沒有通過 gtid_purged 或者通過指定 GTID_NEXT 跳過已經執行的事務 slave 會嘗試去執行這些事務，並且因為主鍵沖突等原因報錯崩潰。

所以現在回頭過來看這幾條命令

set gtid_next='aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10';
begin;
commit;
set gtid_next=automatic;
start slave;

其實它的意義是 首先 :10 這個gtid 是有問題那個 GTID 就是執行了會崩潰的那個 GTID 。

然后這個時候我們對其替換成一個空事務。

再設置之后都正常加一偏移數據。

最后啟動 slave 。這樣的話當我們的 slave 運行到這里的時候會因為已經因為這個 GTID 執行了空事務，而無視跳過 master 傳遞過來的有問題的 binlog 從而達到跳過有問題事務的目的。

 

由於沒有實操過主備切換，這里注意到資料大部分都提到 GTID 模式下只需要指定 change master to 新的機器即可。新的 master 會自動計算相關的位點。

CHANGE MASTER TO MASTER_HOST='xxxx',MASTER_USER='xxx', MASTER_PASSWORD='xxx';
master_auto_position=1

 

 

Reference:

https://yq.aliyun.com/articles/155827  MySQL GTID 主從復制錯誤修復方法

https://www.douban.com/note/446551760/  RESET MASTER 和RESET SLAVE 命令的使用方法 注意事項

https://www.cnblogs.com/zhoujinyi/p/4717951.html  MySQL5.6 新特性之GTID