MySQL 5.7基於GTID複製的常見問題和修復步驟(一)
【問題一】
複製slave報錯1236，是較為常見的一種報錯
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.
需要注意有多種場景都會導致1236錯誤，error code都是1236，但後面的錯誤描述會不同
【產生原因】
這個錯誤發生在slave的IO執行緒從master拉取日誌時，發現gtid_next在master的binlog.index中第一個檔案中不存在。
通常出現在新搭slave , 忘記關閉主庫的binlog備份。
或者slave由於某些原因停止了一段時間，而這段時間master上的binlog被purge掉了，導致從庫獲取不到對應的binlog檔案。
【保證資料一致性的修復步驟】
1、到對應的master上查詢當前gtid_purged值，show global variables like '%gtid%'; 並記錄下來
Variable_name: gtid_purged
Value: 698da8d5-a743-11e7-a2ab-384c4fb16868:1-245780670,
82634550-10fb-11e6-81fc-384c4fb16868:1-1714684630,
cc85f79f-10ff-11e6-8202-384c4fb16888:1-6127989,
fd1bea9b-5194-11e7-bad5-384c4fb16888:1-1579848406
2、在報錯的slave上執行show global variables like '%gtid%';並將gtid_executed記錄下來
Variable_name: gtid_executed
Value: 698da8d5-a743-11e7-a2ab-384c4fb16868:1-242405257,
82634550-10fb-11e6-81fc-384c4fb16868:1-1714684630,
cc85f79f-10ff-11e6-8202-384c4fb16888:1-6127989,
fd1bea9b-5194-11e7-bad5-384c4fb16888:1-1579848406
3、到binlog備份目錄下找被pugre掉的包含 698da8d5-a743-11e7-a2ab-384c4fb16868:1-242405257的GTID的binlog檔案，並從備份目錄拷貝到當前slave伺服器上的目錄
4、在當前slave上執行還原指令碼，直到還原到大於等於gtid_purged的位置，多還原沒有問題，因為已經執行過的GTID，在salve的SQL執行緒重做時會跳過
mysqlbinlog -vvv /data/binlog/bin.file |mysql -u -p
如果出現報錯，可以嘗試匯出SQL檔案source執行
mysqlbinlog -vvv /data/binlog/bin.file > 1059.sql
source 1059.sql
5、start slave;
【不考慮資料一致性的修復步驟】
在某些特殊場景下，比如日誌檔案缺失，需要快速恢復，或是測試環境可以丟失一部分資料
1、master上執行show global variables like '%gtid_executed';並記錄
2、slave上一次依次執行，這種方法會丟失掉上次salve報錯時 Executed_Gtid_Set的位置86c67cfe-8b18-11e8-9e4c-246e965710f8:1-16到新位置86c67cfe-8b18-11e8-9e4c-246e965710f8:1-23之間的，16-23集合的事務
stop slave;
reset master;
set global gtid_purged='86c67cfe-8b18-11e8-9e4c-246e965710f8:1-23';
start slave;
上述方法修復後，都建議用pt-table-checksum工具，檢驗主從資料的一致性。