《MySQL——從刪庫到跑路》阿里架構師分享刪庫跑路救命策略
摘要：
首先看下mysql誤刪資料排名最前的幾種是：
誤刪檔案
誤刪庫、表
錯誤全表刪除 / 更新
升級操作失誤
都來看看你命中過幾個，hoho。
簡單說下我親手造的一個大事故吧。
那大概是一個春暖花開的...
首先看下mysql誤刪資料排名最前的幾種是：
- 誤刪檔案
- 誤刪庫、表
- 錯誤全表刪除 / 更新
- 升級操作失誤
都來看看你命中過幾個，hoho。
簡單說下我親手造的一個大事故吧。
那大概是一個春暖花開的季節，我的內心是激動澎湃的，因為已經安排了休假計劃。在這前幾天，已經把一個新專案的資料庫環境都部署好了，包括自動化備份 。
等我美美的出去玩的時候，悲劇發生了，業務要求進行資料回滾 ，但發現備份檔案不可用，原因是備份時指定的字符集和表字符集不一致 。我勒個擦，原來該專案採用新的字符集，但是我沒有認真檢查確認並修改備份指令碼，結果導致備份失效。最後，因為這個事，當季度績效結果被降檔，boss也為此背鍋～
好吧，回到正題，先說幾點我平時預防誤操作導致檔案/資料丟失不成熟的建議：
-
欲刪除檔案時，將rm命令改成mv，可在系統層面將rm命令做個alias（或參考Windows / Mac OSX做法，刪除檔案時先進回收站）。
刪除資料庫、表時，不要用drop命令，而是rename到一個專用歸檔庫裡； - 刪除表中資料時，不要直接用delete或truncate命令，尤其是truncate命令，目前不支援事務，無法回滾。
- 用delete命令刪除資料時，應當先顯式開啟事務，這樣誤操作時，還有機會進行回滾。
- 要大批量刪除資料時，可以將這些資料insert…select到一個新表，確認無誤後再刪除。或者反其道行之，把要保留的資料寫到新表，然後將表重新命名對掉。
- 執行重要命令之前，先準備好相關命令，再三確認無誤才之行，對於新鳥而言，最好請你的boss坐你旁邊鎮場幾次，否則極有可能會連累大家～
以上幾條，也是我自己奉行的原則。總之，要時刻保持對線上生產環境的敬畏之心 。雖說現在大部分操作可以靠平臺來完成了，但平臺也不是萬能的，不也發生過平臺本身的缺陷造成資料丟失、程式碼回滾、部署失誤等事故嘛，我就不點名了。
做好備份，不管是物理備份還是邏輯備份！
做好備份，不管是物理備份還是邏輯備份！
做好備份，不管是物理備份還是邏輯備份！
重要的事情說三遍都不嫌多。
說完預防措施，我們再說萬一發生誤操作時，怎麼以最快速度進行補救。 我們分別列舉幾種常見的情況：
- 執行DROP DATABASE / DROP TABLE命令誤刪庫表，如果碰巧採用共享表空間模式的話，還有恢復的機會。如果沒有，請直接從備份檔案恢復吧。神馬，你連備份檔案都沒有？那麻煩退出DBA屆吧，一個連備份都懶得做的人，不配成為DBA的。
- 接上，採用共享表空間模式下，誤刪後立刻殺掉（kill -9）mysql相關程序（mysqld_safe、mysqld），然後嘗試從ibdataX檔案中恢復資料。
- 誤刪除正在執行中的MySQL表ibd或ibdataX檔案。請立即申請對該例項進行維護，當然，不是指把例項關閉，而是把業務暫停，或者把該例項從線上環境摘除，不再寫入新資料，然後利用linux系統的proc檔案特點，把該ibd檔案從記憶體中拷出來，再進行恢復，因為此時mysqld例項在記憶體中是保持開啟該檔案的，切記這時不要把mysqld例項關閉了。
- 接上，把複製出來的ibdataX或ibd檔案拷貝回datadir後，重啟mysqld進入recovery模式，innodb_force_recovery 選項從 0 – 6 逐級測試，直至能備份出（整個例項或單表的）所有資料後，再重建例項（或單表），恢復資料。
- 未開啟事務模式下，執行delete誤刪資料。意識到後立即將mysqld（以及mysqld_safe）程序殺掉（kill -9），不要任何猶豫，然後再用工具將表空間資料讀取出來。因為執行delete刪除後，實際資料並沒被物理清除，只是先打上deleted-mark標籤，後續再統一清理，因此還有時間差。
- 執行truncate誤清整表。如果沒使用共享表空間模式的話，基本別想了，走備份恢復+binlog吧。
- 執行不帶where條件的update，或者update錯資料。也別費勁了，走備份恢復+binlog吧