MySQL 5.7基於GTID複製的常見問題和修復步驟(二)
【問題二】
有一個叢集(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複製的常見問題和修復步驟(一)