MySQL數據恢復的一些補充 這是學習筆記的第 2056 篇文章 如果一個線上數據庫發生了問題，需要做數據恢復，作為DBA應該給自己留一些改進的余地，否則陷入兩難的境地，只會讓自己更加被動。 我可以隨便舉出一些異常的場景。 一個預置賬戶 比如我們的數據文件在/data下面，這個目錄下有多個實例的相關數據文件，如果把這個目錄誤刪除了，那么我們還是存在一些恢復的可能性的，這個時候我們是無法通過句柄恢復，但是可以通過mysqldump的方式轉儲數據文件，在數據量不大的情況下算是一個救命的方法了，當然這里我們必然要做好準備，那就是推薦配置一個管理員賬號，基于本機即可，需要注意的是MySQL里面主機localhost默認是基于socket方式，而主機為127.0.0.1則默認是基于TCP/IP的連接方式，這種異常情況下，只有TCP/IP的方式依舊可靠，希望這個賬戶平時不需要用到，但是在一些關鍵時刻能夠充分的使用到。 線上環境應該杜絕drop操作 在我的理解中，DBA是否有drop權限是一件值得討論的事情。我們不能想當然的認為因為是DBA所有應該有drop權限。 在MySQL里面，基于它的設計方式（8.0之后有了默認的共享表空間，情況發生了變化），在5.7及以下版本中，完全可以通過rename操作完成，比如我們設置一個數據庫test,它的歸檔數據庫為test_arch，那我們的用戶對有test_arch才有drop權限，而其他線上用戶都應該杜絕，同類低于truncate操作也需要格外謹慎。 可用的備份 關鍵時候恢復的時候，如果發現備份存在問題不夠完整，那么就失去了整個備份恢復的最后一根稻草。至于備份的方式，可以綜合根據數據量使用情況來進行選型，比如阿里云的默認是物理備份的方式，可以根據實際的業務特點進行方案的對齊。 必要的表結構備份 通常在物理/邏輯的全庫備份中，可以把表結構的備份也融入進去，一般來說備份表結構，這個操作基本是秒級完成，從時間成本上來說不存在問題，而有時候我們需要的僅僅是一些結構的信息，如果表數量比較大，那么使用表結構的邏輯備份就派上用場了。 異常恢復的一些技巧 上面的是一些常規的操作場景，至少有了備份恢復是可行的，但是我們不能指望一定是最完美的方案，我們需要在技能上占領高地，提前儲備一些技能，以防數據恢復時的被動。 解析.frm文件得到DDL 基于ibd文件的數據恢復 基于句柄的數據恢復方法 基于DML閃回方案的補充測試 這些方法，除了常規的備份之外，我們需要儲備這些硬技能，讓那些艱難的數據恢復場景有了一些可行性，而這個是作為后備方案，來對已有的恢復異常提供補充。