【問題二】

有一個集群（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復制的常見問題和修復步驟(一)

MySQL 5.7基於GTID復制的常見問題和修復步驟(二)