從bug92252來看GTID複製協議

簡介

大概意思如下 在使用GTID協議協議進行復制時，slave設定了複製錯誤跳過選項，當出現相應的錯誤時，並不會中斷sql回放執行緒，於是會出現GTID空洞的現象，這些事務在主庫上是執行過的，但是在從庫中並沒有執行過。那麼問題就來了，當主庫由於binlog過期時間設定，或者手動purged掉這部分GTID後，如果從機執行stop slave，start slave操作，則IO執行緒會報GTID被purged掉的錯誤。

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.'
 

問題原因

這涉及到基於GTID的複製在建立複製連結是，如何尋找複製起始位點，這部分程式碼在

Binlog_sender::check_start_file()

master找點的邏輯為

• 將當前所有的binlog檔名加入一個list
• 倒序檢視每一個binlog檔案中的Previous-GTIDs,判斷Previous-GTIDs是否是從機GTID_executed的子集，如果是，則從當前binlog檔案開始複製。
• 開始從此檔案為起點，開始send_binlog.
• 過濾此檔案中每一個存在於從機GTID_executed中的事務。

所以如果master當前儲存的binlog的Previous-GTIDs都不是slave GTID_executed的子集，則會報錯，無法建立複製連結。

解決辦法

解決辦法就是在從機上通過set gtid_purged的方式，手動去填補這些空缺。