'MySQL誤刪數據庫程序員救命指南 教你跑路老闆都找不到的那種'

程序員刪庫後怎麼面對老闆？我教你們

言歸正題

事情緣起有次上課，大家聊起親手造了啥大故障，排名最前的幾種是：

• 誤刪文件。
• 誤刪庫、表。
• 錯誤全表刪除 / 更新。
• 升級操作失誤。
• 沒有備份
• 硬盤損壞

自己看看曾經命中幾個。

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

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

等我美美的出去玩一整天回來的時候，不幸悲劇還是發生了，業務要求需要進行數據回滾，但是我驚訝的發現備份文件竟然不能使用，查了一下午終於找到原因是應為“” 備份時指定的字符集和表字符集不一致”。我勒個擦，原來該項目採用新的字符集，但是我沒有認真檢查確認並修改備份腳本，結果導致備份失效。最後，因為這個事，當季度績效獎金統統被降檔，我的直屬大boss也為此背鍋～ 熬

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

1. 欲刪除文件時，將rm命令改成mv，可在系統層面將rm命令做個alias（或參考Windows / Mac OSX做法，刪除文件時先進回收站）。
2. 刪除數據庫、表時，不要用drop命令，而是rename到一個專用歸檔庫裡；
3. 刪除表中數據時，不要直接用delete或truncate命令，尤其是truncate命令，目前不支持事務，無法回滾。
4. 用delete命令刪除數據時，應當先顯式開啟事務，這樣誤操作時，還有機會進行回滾。
5. 要大批量刪除數據時，可以將這些數據insert...select到一個新表，確認無誤後再刪除。或者反其道行之，把要保留的數據寫到新表，然後將表重命名對掉。
6. 執行重要命令之前，先準備好相關命令，再三確認無誤才之行，對於新鳥而言，最好請你的boss坐你旁邊鎮場幾次，否則極有可能會連累大家～

7.用事務保護。在更新數據和刪除數據時，要特別留意比如忘記寫where或者寫錯了where的情況。所以始終要預先確定要更新/刪除的行有多少條。但DBA不可能總是清楚即將會變更多少行數據，所以需要由SQL執行的提出者先從生產庫上執行select拿到大致要修改的數據量，然後與DBA確認。

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

如果真的刪除了怎麼辦？

-----做好備份，不管是物理備份還是邏輯備份！

說完預防措施之後，再說如果發生誤操作時，怎麼做才能以最快的速度搶救。 我們分別列舉幾種常見的情況：

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吧。

如果以上都沒有救怎麼辦？？？？

或許你會想到更好的辦法進行補救，總之人在絕境的情況下也許會發生點奇蹟，不是嗎？

如果你什麼方法都試了還是沒有用怎麼辦？

此時你最應該做的就是老闆發現之前跑路了。。。。

"

程序員刪庫後怎麼面對老闆？我教你們

言歸正題

事情緣起有次上課，大家聊起親手造了啥大故障，排名最前的幾種是：

• 誤刪文件。
• 誤刪庫、表。
• 錯誤全表刪除 / 更新。
• 升級操作失誤。
• 沒有備份
• 硬盤損壞

自己看看曾經命中幾個。

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

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

等我美美的出去玩一整天回來的時候，不幸悲劇還是發生了，業務要求需要進行數據回滾，但是我驚訝的發現備份文件竟然不能使用，查了一下午終於找到原因是應為“” 備份時指定的字符集和表字符集不一致”。我勒個擦，原來該項目採用新的字符集，但是我沒有認真檢查確認並修改備份腳本，結果導致備份失效。最後，因為這個事，當季度績效獎金統統被降檔，我的直屬大boss也為此背鍋～ 熬

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

1. 欲刪除文件時，將rm命令改成mv，可在系統層面將rm命令做個alias（或參考Windows / Mac OSX做法，刪除文件時先進回收站）。
2. 刪除數據庫、表時，不要用drop命令，而是rename到一個專用歸檔庫裡；
3. 刪除表中數據時，不要直接用delete或truncate命令，尤其是truncate命令，目前不支持事務，無法回滾。
4. 用delete命令刪除數據時，應當先顯式開啟事務，這樣誤操作時，還有機會進行回滾。
5. 要大批量刪除數據時，可以將這些數據insert...select到一個新表，確認無誤後再刪除。或者反其道行之，把要保留的數據寫到新表，然後將表重命名對掉。
6. 執行重要命令之前，先準備好相關命令，再三確認無誤才之行，對於新鳥而言，最好請你的boss坐你旁邊鎮場幾次，否則極有可能會連累大家～

7.用事務保護。在更新數據和刪除數據時，要特別留意比如忘記寫where或者寫錯了where的情況。所以始終要預先確定要更新/刪除的行有多少條。但DBA不可能總是清楚即將會變更多少行數據，所以需要由SQL執行的提出者先從生產庫上執行select拿到大致要修改的數據量，然後與DBA確認。

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

如果真的刪除了怎麼辦？

-----做好備份，不管是物理備份還是邏輯備份！

說完預防措施之後，再說如果發生誤操作時，怎麼做才能以最快的速度搶救。 我們分別列舉幾種常見的情況：

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吧。

如果以上都沒有救怎麼辦？？？？

或許你會想到更好的辦法進行補救，總之人在絕境的情況下也許會發生點奇蹟，不是嗎？

如果你什麼方法都試了還是沒有用怎麼辦？

此時你最應該做的就是老闆發現之前跑路了。。。。

"