背景：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 statusG上看到主庫的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