背景：MySQL5.6.40，庫比較小，row+gtid複製環境，但由於以前種種原因，備份還原在從庫後，開啟複製存在大量1062,1032錯誤，gtid卡在靠前位置。做複製的時候沒有任何從庫，每小時的備份也被運維停了。以前從來沒遇到過這種情況，相對測試環境正式環境比較複雜，而且猜測可能是之前備份還 ...

背景：MySQL5.6.40，庫比較小，row+gtid複製環境，但由於以前種種原因，備份還原在從庫後，開啟複製存在大量1062,1032錯誤，gtid卡在靠前位置。做複製的時候沒有任何從庫，每小時的備份也被運維停了。

以前從來沒遇到過這種情況，相對測試環境正式環境比較複雜，而且猜測可能是之前備份還原從來沒用過備份一致性參數導致，並且發現錯誤也沒有手工檢查（這個問題還在研究中，有遇到並知道原因的小伙伴歡迎指導）。

為了今後避免因為恢復不及時導致的數據丟失，特別總結本次故障過程和大家討論、分享。

簡化時間軸如下圖：

開始---->備份主庫---->恢復從庫---->複製error1032，1062---->刪除從庫再次恢復---->複製error1032，1062---->reset master從庫、主庫---->準備刪除從庫---->誤操作刪主庫----->恢復主庫----->跳過大量1062、1032錯誤---->找drop db位置恢復從庫---->對比主從數據---->手工補數據---->結束

下麵按照我的記憶描述下當時的場景：

一、首次備份主庫、搭建從庫

第一次搭建從庫，從主庫的備份未使用master-data=2 single-transaction（保證事務備份時的一致性）參數遷移後，報大量1062和1032錯誤（家家有本難念的經，不多說了）

二、第二次還原主庫到從庫

於是第二次重新導入。

同樣報錯。在導入從庫前使用reset master；將從庫binlog清除。

由於操作人員不瞭解reset master含義及執行結果，又在主庫做了reset master；

結果導致主庫所有binlog日誌被清除並且binlog position置為1；

這裡貼以下官方說明，別沒事幹就在主庫上用這條。

再次導入發現依舊大量報1032，1062錯誤。

由於懷疑是因為備份時沒使用--single-transaction參數，準備刪除從庫，加參數重新備份主庫。

三、誤刪除主庫

結果誤操作刪除主庫（這個鍋一部分原因要甩給mysql naivcat這個工具，垂直排列庫，稍微不註意就容易點錯。還是建議大家聽吳老師的用官方的workbench），刪庫還是兩人校對，在操作系統上執行，刪前沒把握最好備份一遍。

刪庫這種操作謹慎謹慎再謹慎，重要的事情說三遍！

drop database;（在naivcat上右鍵刪除庫，但binlog日誌中還是會記錄DROP DATABASE這條記錄）

這時候為了保證業務不中斷，立馬在主庫上通過之前的備份文件恢復了一套庫，當然數據肯定丟失了，但可以推算丟失數據的時間段（從備份完畢開始--->DROP DATABASE）。

PS.請不要問我為什麼刪庫，為什麼刪完又恢復了一套庫，因為都不是我乾的。。。。。。

萬幸的是誤刪除主庫但並未刪除從庫，而且從庫的io_thread仍然處於yes狀態（回顧吳老師的課程，也就是說雖然庫被刪除了但其實刪庫前的數據=備份數據+io_thread已下載的刪除主庫前的數據），由於sql_thread仍然停到gtid靠前的位置

四、跳過大量1032，1062錯誤

這個時候只要看下備份文件的gtid位置，並purge到該位置（之前備份丟了，隨便找了一個備份的截圖，理解萬歲）。

##這裡說明一下為什麼直接purge到備份的結尾位置，因為書庫備份的數據中1032和1062錯誤太多，且主庫已經刪除沒辦法通過腳本對比跳過大量1032，1062錯誤（吳老師友情提供），在能夠保證是從主庫邏輯備份過來的情況下（主從數據一致），我們選擇快速跳過大量錯誤（偷懶加情況急），直接purge到備份最後的位置。

##上圖是隨便截的一個備份文件最開頭的位置，請忽略那個gtid的值，意思明白就行。

set @@gtid_purged='fb1f83af-1915-11e8-811b-000c29c4d77d:1-500';

註：‘500’代表備份文件最後一個執行的事務的gtid。gtid_purged代表資料庫已經在從庫上重放過1-500這段事務。

五、找到主庫DROP DATABASE的GTID位置

purge到該位置然後再確定drop database的位置上（思路：如果不確定dropdatabase的位置就start slave 那麼從庫會應用主庫的binlog也就會執行主庫drop database的操作，為了避免從庫重放主庫drop database的操作，我們要設法讓gtid在從庫停到drop database前一個gtid的位置）

註：可以通過大致刪庫時間或者從從庫的show slave status\G上看到主庫的binlog位置從後往前找DROP DATABASE的位置，如果刪庫後做了reset master那就只能從從庫的relay-bin-log上找了（切記主庫沒事別reset master）；

mysqlbinlog -vvv --base64-output=decode-rows relay-bin.000017

六、啟動從庫SQL_THREAD

在從庫上執行start slave sql_thread until的命令，這裡需要說明，因為主庫已經還原，業務跑起來了，這時候開啟io_thread沒有什麼意義，所以只用讓從庫的sql_thread線程重放DROP DATABASE之前的事務就行。

root@localhost[{none}]>start slave sql_thread until sql_before_gtid='fb1f83af-1915-11e8-811b-000c29c4d77d:2343';

啟動slave，並且讓從庫gtid停在主庫drop database操作之前一個gtid就可以，再還原到主庫就能立馬投入使用，還不會導致數據丟失。

確保從庫executed_gtid_set到了我們before的前一個值就可以備份了，然後dump這份數據還原主庫，當然如果從庫性能不錯的話可以考慮應用端更改連接，這樣速度更快一些。

但比較麻煩的就是，要保證生產的實時性，刪庫後立即在主庫上還原了之前用來恢復從庫的備份文件，這就肯定會導致中間數據丟失。

七、數據對比還原

這時候只能使用用之前用來搭建從庫的備份再恢復一個庫，再用pt-table-checksum對比主庫和恢復庫，從庫和恢復庫不一致的數據，用pt-table-sync生成對應語句。然後手工把數據補進系統中。

對比1：主庫：備份數據還原的庫---->目標：找到主庫在刪庫之後應用又寫入了哪些數據。

對比2：從庫：備份數據還原的庫---->目標：找到備份數據之後，刪庫之前應用在主庫里寫了哪些數據。

因為量不是很大，手工對比一下就行，當然數據還原的坑也有很多，不過基本上都被研發填了。

總結：

頭一回碰到刪庫情況還是有點蒙，還好主庫用的是GTID找binlog日誌中的位置相對容易一點。這次恢復最幸運的就是還好從庫卡在靠前的位置，要不然即使有了從庫，數據也會被刪了，恢復起來相對更麻煩些。

對於gtid的恢復，課上吳炳錫老師都講過，但是一上手還是慢了幾拍，還是要通過實戰多練習加深手感避免在真實情況下懵逼。

最後特別鳴謝：知數堂葉金榮老師和吳炳錫老師在故障發生時給予的幫助和支持。

轉載請註明出處 https://www.cnblogs.com/Lemon-DBA/p/9396546.html

一次事故的回顧