記一次程序員恢復MySQL數據庫主從過程

相信大家的項目都是使用主從模式的數據庫吧，我們在開發中可能要維護主從的情況比較少，只需要寫增刪改查就夠了。但是最近自己經歷一次主從異常的恢復。也算是有一份不一樣的收獲吧。

由于項目使用MySQL主從備份模式，在某一天因為數據異常導致數據庫主從斷開，釘釘也開始報警;

從釘釘告警可以知道，從庫的SQL線程斷了，原因在于從庫沒有該條數據，但是現在需要從庫更新這條數據，導致的報錯。

想要恢復主從，但是沒有專業的DBA來恢復。怎么辦？只有開發上場了恢復了。

最初我的思路是：

跳過異常的數據點

說干就干

這里我先在從庫中操作：

然后我們跳過有異常的這條記錄：

重新啟動從庫線程:

查看從庫還有沒有異常信息：

發現又出現新的錯誤：

然后我們有跳過上面的錯誤點，發現還是會出現新的錯誤。最后干脆批量跳過。

這里我將90355471-109617802的記錄點都跳過。查看從庫狀態，發現IO線程和SQL線程都好了。終于可以放松一會了。

結果第二天發現，又報錯了。看來不能用跳過的方法了。因此我準備重新來一次完整的同步。

主要過程為：備份主庫數據；重置主庫和從庫服務；刪除從庫數據，并將主庫備份的數據還原到從庫庫中；重新開啟主從同步；

在備份數據前我們需要給主數據庫開啟只讀功能。

在主庫中操作

然后備份數據：

這里我們指定database，如rxx。

等待了30分鐘左右，數據備份完畢，看一下sql文件，大概36GB左右。

然后將備份的sql文件拷貝到從庫中：

現在將master服務重置（主庫中操作）：

解鎖主庫：

接下來需要在從庫中操作了。

先刪掉從庫上面的數據庫：

然后創建一個新的庫 xxx：

將主庫備份的數據還原到從庫上：

tips：恢復時間比較長，大概40分鐘左右，需要耐心等待

最后我們重置slave服務，并且開啟slave服務。

查看下從庫狀態，發現IO線程和SQL線程都已經正常了。