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