【問題二】

有一個叢集（MySQL5.7.23）切換後複製slave報1236，其實是不小心在slave上執行了事務導致

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.

【產生原因】

定時任務在執行flush slow logs前未加set sql_log_bin=0;導致在slave上執行時，slave上的GTID增長，當binlog日誌被purge後，發生MHA切換後就會報出上面的錯誤。

【修復步驟】

下面描述正確的處理步驟：

1、切換後如果出現replication報錯，第一時間先關閉master的binlog備份

2、修復導致slave事務增長的job指令碼set sql_log_bin=0; flush slow logs

3、slave上stop slave;

4、master上show global variables like '%gtid%';記錄gtid_purged，gtid_executed值

5、slave上reset master;

6、slave上set global gtid_purged='3d9ade83-7cea-11e5-bc12-d89d6725f98c:1-863017556,

8fad86b1-8980-11e8-873d-40a8f024a124:1-24531;

這裡需要注意，設定的值應該是上面截圖紅色框兩段組合的值，這樣才能保證再次切換後複製正常

7、slave上start slave;

對於這次的場景，按上次步驟恢復後會丟失8fad86b1-8980-11e8-873d-40a8f024a124:1-24531這段事務，但這段事務實際上是flush slow logs事務，並不影響業務資料，因此理論上資料會一致

上述方法修復後，建議用pt-table-checksum工具，檢驗主從資料的一致性。

複製相關的文章

MySQL 5.7基於GTID複製的常見問題和修復步驟(一)