《MySQL——從刪庫到跑路》阿里架構師分享刪庫跑路救命策略

首先看下mysql誤刪數據排名最前的幾種是：

• 誤刪文件
• 誤刪庫、表
• 錯誤全表刪除 / 更新
• 升級操做失誤

都來看看你命中過幾個，hoho。

簡單說下我親手造的一個大事故吧。

那大概是一個春暖花開的季節，個人心裏是激動澎湃的，由於已經安排了休假計劃。在這前幾天，已經把一個新項目的數據庫環境都部署好了，包括自動化備份。

等我美美的出去玩的時候，悲劇發生了，業務要求進行數據回滾，但發現備份文件不可用，緣由是備份時指定的字符集和表字符集不一致。我勒個擦，原來該項目採用新的字符集，可是我沒有認真檢查確認並修改備份腳本，結果致使備份失效。最後，由於這個事，當季度績效結果被降檔，boss也爲此背鍋～

好吧，回到正題，先說幾點我平時預防誤操做致使文件/數據丟失不成熟的建議：

1. 欲刪除文件時，將rm命令改爲mv，可在系統層面將rm命令作個alias（或參考 Windows / Mac OSX作法，刪除文件時先進回收站）。

刪除數據庫、表時，不要用drop命令，而是rename到一個專用歸檔庫裏；

1. 刪除表中數據時，不要直接用delete或truncate命令，尤爲是truncate命令，目前不支持事務，沒法回滾。
2. 用delete命令刪除數據時，應當先顯式開啓事務，這樣誤操做時，還有機會進行回滾。
3. 要大批量刪除數據時，能夠將這些數據insert…select到一個新表，確認無誤後再刪除。或者反其道行之，把要保留的數據寫到新表，而後將表重命名對掉。
4. 執行重要命令以前，先準備好相關命令，再三確認無誤才之行，對於新鳥而言，最好請你的boss坐你旁邊鎮場幾回，不然極有可能會連累你們～

以上幾條，也是我本身奉行的原則。總之，要時刻保持對線上生產環境的敬畏之心。雖然說如今大部分操做能夠靠平臺來完成了，但平臺也不是萬能的，不也發生過平臺自己的缺陷形成數據丟失、代碼回滾、部署失誤等事故嘛，我就不點名了。

作好備份，無論是物理備份仍是邏輯備份！
作好備份，無論是物理備份仍是邏輯備份！
作好備份，無論是物理備份仍是邏輯備份！

重要的事情說三遍都不嫌多。

說完預防措施，咱們再說萬一發生誤操做時，怎麼以最快速度進行補救。 咱們分別列舉幾種常見的狀況：

1. 執行DROP DATABASE / DROP TABLE命令誤刪庫表，若是碰巧採用共享表空間模式的話，還有恢復的機會。若是沒有，請直接從備份文件恢復吧。神馬，你連備份文件都沒有？那麻煩退出DBA屆吧，一個連備份都懶得作的人，不配成爲DBA的。
2. 接上，採用共享表空間模式下，誤刪後馬上殺掉（kill -9）mysql相關進程（mysqld_safe、mysqld），而後嘗試從ibdataX文件中恢復數據。
3. 誤刪除正在運行中的MySQL表ibd或ibdataX文件。請當即申請對該實例進行維護，固然，不是指把實例關閉，而是把業務暫停，或者把該實例從線上環境摘除，再也不寫入新數據，而後利用linux系統的proc文件特色，把該ibd文件從內存中拷出來，再進行恢復，由於此時mysqld實例在內存中是保持打開該文件的，切記這時不要把mysqld實例關閉了。
4. 接上，把複製出來的ibdataX或ibd文件拷貝回datadir後，重啓mysqld進入recovery模式，innodb_force_recovery 選項從 0 – 6 逐級測試，直至能備份出（整個實例或單表的）全部數據後，再重建實例（或單表），恢復數據。
5. 未開啓事務模式下，執行delete誤刪數據。意識到後當即將mysqld（以及mysqld_safe）進程殺掉（kill -9），不要任何猶豫，而後再用工具將表空間數據讀取出來。由於執行delete刪除後，實際數據並沒被物理清除，只是先打上deleted-mark標籤，後續再統一清理，所以還有時間差。
6. 執行truncate誤清整表。若是沒使用共享表空間模式的話，基本別想了，走備份恢復+binlog吧。
7. 執行不帶where條件的update，或者update錯數據。也別費勁了，走備份恢復+binlog吧