刪庫後，除了跑路還能怎麼辦？
閱讀本文大概需要 1.4 分鐘。
當年悟空學藝於菩提祖師門下，老師遣他下山，悟空覺得自己蒙受師傅傳授大恩，還沒有報答。菩提祖師就說：不要提什麼報答之恩，只要你日後闖出禍來不把為師說出來就行了。
我聽說過挺多刪庫的事件，於是開玩笑的略改一下：“日後你刪了庫後，不要把師傅說出來就行了”，不知道那些刪庫的工程師們，其師傅有沒有交代過這句話，emmm。。。
話說日後，孫悟空真的刪過一個數據庫裡的記錄，這就是：生死薄。
孫悟空壽命只有342歲，在大鬧地府那天其實陽壽已盡，在原著中曾這樣寫道：
“悟空親自檢閱，直到那魂字一千三百五十號上，方注著孫悟空名字，乃天產石猴，該壽三百四十二歲，善終。”
孫悟空哪能受得了這個，拿起生死簿把自己的名字就劃了，不僅如此，他也不能讓自己的猴子猴孫也經歷生老病死，便順手把生死簿中所有的猴子都給劃掉了。
所以問題來了：
生死簿，這個龐大的資料庫系統，如果沒有災備，沒有備份，只有當前態，其資料就被永久的改變了。無可挽回。
從表象來看，生死薄是一個平板檔案的日誌記錄，但是事實上並非如此，這內部一定是一個龐大而複雜的資料庫系統，其中：
要儲存所有生靈的出生壽元；
要儲存所有生靈的善惡功德；
要儲存所有的前世今生迴圈；
要儲存所有生靈的關係關聯；
要高併發高吞吐全宇宙聯網；
大家想想這個資料結構要怎麼設計？
資料量實在太大，分庫分表分散式，這是少不了的；
主鍵唯一如何規劃？
前世今生生生不息，關係網實在複雜；
天災人禍批量處理高併發；
前車之鑑，容災備份高可用必須要有？
太複雜了，還是作為面試題，找幾個人問問，或者招個標搞個方案吧！
投標應標咱不管了，可是刪除了資料庫怎麼辦？
等傳票？拿護照？跑路去？nonono ！以 MySQL 為例，這裡對刪庫語句做下分類：
1. 使用 delete 語句誤刪資料行，通過閃回 +binlog 可以找回；
2. 使用 drop table/database 或者 truncate table 語句誤刪資料庫/表，通過全量資料定期備份 +binlog 可以找回；
3. 使用 rm -rf 命令誤刪整個 MySQL 例項，只要還有備份節點就可以找回。
一分鐘系列的文章，篇幅有限，這裡只簡單介紹下采取什麼補救措施，不寫詳細內容，想看詳細的文章，可以在下方或後臺給我留言。
操作需謹慎，刪庫別跑路！
·END·
程式設計師的成長之路
路雖遠，行則必至
微信ID:cxydczzl
往期精彩回顧