一次Mysql主從復(fù)制出現(xiàn)1236錯(cuò)誤解決全過程

自己搭建了一套mysql5.7.26的主從復(fù)制環(huán)境，有2個(gè)多月沒怎么管它，今天上去想要做一個(gè)因?yàn)橹麈I沖突，導(dǎo)致失敗的測試，發(fā)現(xiàn)mysql主從復(fù)制已經(jīng)斷開了，上去一看報(bào)了1236錯(cuò)誤，詳細(xì)錯(cuò)誤信息如下所示：

Last_IO_Error: 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.'，看這個(gè)報(bào)錯(cuò)信息，是由于復(fù)制需要的binary logs被刪除了，所以導(dǎo)致主從復(fù)制失敗，去主庫上查看，日志已經(jīng)沒有了，這也就無法正常啟動(dòng)復(fù)制進(jìn)程了。

到這里，有2個(gè)解決方案第一：重新搭建主從復(fù)制，在主庫上做個(gè)全備，在從上庫上恢復(fù)，然后配置主從復(fù)制第二：由于是測試環(huán)境，數(shù)據(jù)的一致性不太重要，不用主從的復(fù)制的數(shù)據(jù)保持一致了，可以清除已經(jīng)刪除的binary logs日志的gtid信息，重啟主從復(fù)制。

方法如下所示：1.在主庫上獲取gtid_purged信息

2.登錄從庫，停止slave服務(wù)，重置slave

至此，主從復(fù)制已經(jīng)恢復(fù)正常，當(dāng)然在生產(chǎn)上不建議使用此方法，因?yàn)榇朔椒?，會?dǎo)致主從數(shù)據(jù)不一致，在開發(fā)，測試環(huán)境是可以用的。