下廚房6月26日數據丟失事故總結 MYSQL主分區被rm 命令誤刪除
下廚房6月26日數據丟失事故總結 MYSQL主分區被rm 命令誤刪除
http://tech.xiachufang.com/?p=18php
在6月26日凌晨12點左右，咱們在作線上數據庫的備庫時，誤將線上數據庫分區上的全部文件刪除。丟失的數據時間段爲4月23日至6月25日兩個月，在通過7天的努力後，恢復了99%以上的數據。（具體見下面的統計）。python
下面把整個事故過程記錄下來，令關心本次技術事故的人們知曉。mysql
一. 事故隱患
如今回顧，事故隱患在4月23日以後就已經存在。linux
咱們線上數據庫使用的是MySQL，在4月23日以前，咱們對線上數據庫主節點有三類備份。一是有一個獨立的數據庫從節點來備份，與線上服務器保持數據的實時同步，須要時可切換做線上使用。二是會按期把整個數據庫dump成sql文件來備份，一天保存一次，備份的來源是數據庫從節點。三是主節點開啓有binlog 拷binlog，默認是保存十天的binlog，十天內有任何事故能夠從日誌裏完整恢復所有數據。這三個備份分別存放在兩臺不一樣的物理機，三個不一樣的分區上，是當時想到的最安全的方式。程序員
4月23日，咱們把數據庫主節點遷移到一臺新的物理機上，並把版本升級到5.5。因爲版本和配置的問題，原來的從節點並不能直接使用。而一天一次的備份來源是從節點（備份主節點會令網站和手機app有1小時左右的卡頓），這個備份方式也就中止了更新。只有最後一個binlog還在運行。數據庫遷移以後應用服務器存在一些性能問題須要投入時間，包括修復MySQL5.5版本和原代碼的兼容，以及把應用服務器從gunicorn換成uwsgi Python的web代理，以後又陸續有一些開發任務，以至從新啓用備份節點的工做一再拖延。web
咱們對數據庫遷移工做的管理存在失誤，是形成事故的根本緣由。沒有完成數據庫備份節點，遷移工做就並無結束。咱們技術團隊的全部人對這個事故都負有責任，這個隱患在兩個月裏均可能被發現，每一個人都有可能提出這個工做的高優先級。也均可能提出相應的彌補工做來保證數據安全，好比在啓用從節點前延長二進制日誌的保存時間等。是咱們的工做失誤使數據庫成爲系統最脆弱的環節，經受不住偶然事故的衝擊。sql
二. 事故發生過程
6月26日凌晨12點左右，咱們開始從新創建備份節點的工做，須要把原來的從節點刪除，從新安裝，因此先使用了rm -f方式刪除備份節點分區上的全部文件。數據庫
5分鐘後，發現剛纔刪除的是數據庫主節點的分區，爲防止硬盤繼續寫入，就立刻把mysql進程中止了。全部技術人員開始應急處理。一是把整個分區dd成鏡像，準備作未來硬盤恢復的備份。二是把memcache裏的數據dump出來，以備可能的恢復。三是從新啓用原來的從數據庫，因爲數據時間只到4月23日，須要調整近兩月表結構變動，讓最新的代碼能夠跑起來。vim
當天的應急工做至凌晨4點，服務器都恢復訪問，但數據停留在4月23日。安全
在整個應急過程當中，部分是緊張，部分是溝通上存在誤解，仍是出現了失誤。當配置從數據庫的技術人員完成以後，重啓了服務器和memcache，恢復了正常訪問。可是作memcache導出工做的技術人員尚未完成，因此最終能從memcache裏獲得的那部分數據只有一半左右。
過後從沃趣科技的數據庫工程師那裏得知，咱們第一時間中止MySQL防止硬盤繼續寫入這個應急措施是錯誤的，即便分區徹底沒有文件，mysql的進程繼續運行，只要保留這個現場，能夠從內存中獲取更多的數據庫結構信息，對恢復數據很是有幫助。
三. 事故後恢復工做
事故後恢復工做從數據來源分爲4條線索進行： 1. 硬盤上數據的恢復（主線） 2. 從memcache導出的數據恢復 3. 從binlog裏恢復 4. 從搜索引擎的快照裏恢復頁面
如下按時間詳細敘述：
- 6月26日8點，咱們去機房把服務器硬盤取出來，送到了一家硬盤數據恢復公司。到下午5點左右恢復出ibdata1文件，文件可能破損。
- 6月26日12點，爲了預防新插入的內容和原內容的衝突，咱們把全部表的id都加到一個大值，半天的內容隨後作特殊處理。
- 6月26日23點，導入完了全部memcache裏的數據。
- 6月27日上午，從硬盤裏又恢復出部分.ibd文件，也包含部分數據信息。已肯定包含數據的ibdata1和.ibd文件有破損，沒法直接使用，只能嘗試從破損文件中提取部分有效信息。
- 6月27日下午，聯繫上杭州沃趣網絡科技有限公司的陳棟、李春，開始對數據的提取工做。至凌晨1點，提取出.ibd文件的數據，恢復部分表。
- 6月28日全天，沃趣科技開始對ibdata1文件的提取，至29日凌晨1點，他們已經提出大部分數據。
- 6月28日下午，獲得阿里巴巴集團的周振興的友情支持，他開始幫忙作ibdata1文件的提取工做，至凌晨4點，他完成部分帶二進制段的數據表的修復，提取到了相關內容。
- 6月28日下午，咱們聯繫上北亞數據恢復中心，開始再次嘗試對硬盤文件的恢復。
- 6月28日晚，咱們把全部從binlog來的數據導入完，完整恢復了最後10天的數據。
- 6月29日中午，從沃趣科技獲得的優先級較高的數據表已經恢復完成，開始恢復次優先級的數據。
- 6月30日中午，提取完全部能從6月27日獲取的破損數據庫文件裏的全部內容。至此這一階段提取到缺失總數據量的近70%。
- 6月30日下午，開始從搜索引擎快照裏抓取部分菜譜重要頁面，修補缺失的內容。並聯繫上某搜索引擎的快照部門，但願獲取咱們網站的所有頁面快照。
- 7月1日上午，北亞數據恢復中心取得很大的進展，提取到幾乎是完整的ibdata1文件，至下午6點，提取到除了收藏和讚的全部數據表，咱們開始把數據導入，至凌晨4點，恢復完獲得的全部數據。
- 7月2日成天，因爲導入的舊數據和新註冊的用戶存在部分數據不一致，咱們盡力配合用戶恢復。
- 7月2日下午4點，北亞提取到ibdata1剩下的文件碎片，獲得了完整的ibdata1文件，mysql無報錯啓動，咱們獲得了6月26日凌晨事故前的完整數據庫。至凌晨2點，咱們提取出剩下的收藏和贊，恢復到數據庫裏。至此損失的數據內容已經恢復到99%。
下一階段：
- 在丟失兩個月數據的這一週時間裏，用戶新產生的數據和恢復的舊數據會有少許不兼容的狀況，咱們會全力幫助用戶找回本身的所有數據，出現的錯誤敬請用戶包涵，幫助咱們走過這一過渡階段。
- 除了原先的三種備份方式外，咱們會繼續落實和第三方的雲存儲方案的合做，把數據備份到咱們的服務器以外的地方。
四. 所缺失的近兩月數據當前的恢復狀況
至今，內容大多獲得了99%左右的恢復。缺失部分並非來自硬盤數據丟失，而是6月26日12點前id移位至大值前，半天建立的內容和原位置內容的衝突，咱們還在盡力修補。
如下是當前主要內容的恢復狀況：
| 菜譜 | 收藏 | 贊 | 做品 | 關注 | 菜單 | 用戶 | |
| 恢復比例 | 99.0% | 98.6% | 99.2% | 99.5% | 99.5% | 99.3% | 99.1% |
五. 致謝
特別感謝一下三個公司和我的在這7天的恢復工做中對咱們的幫助。
杭州沃趣網絡科技有限公司(@沃趣科技)是來自原阿里巴巴DBA/SA團隊核心骨幹組建的創業公司，提供數據庫和系統相關的專業服務和產品，陳棟（@grassbell）、李春（@pickup112）對破損的數據庫文件進行了災難修復，提取出絕大部分數據表的內容。
周振興（@orczhou）是淘寶MySQL數據庫運維負責人，他對破損文件中部分帶二進制段的數據表進行了修復，提取到了相關內容。
北亞數據恢復中心是來自前信息產業部職鑑中心，專門從事數據恢復服務的技術公司。張宇，劉子龍對硬盤文件進行了完整的恢復，使咱們獲得了數據庫的所有數據。
This entry was posted in Uncategorized on July 3, 2013
Post navigation
43 thoughts on 「下廚房6月26日數據丟失事故總結」
xenon@ribosome /proc/4933/fd $ ll /proc/4933/fd 總用量 0 dr-x—— 2 xenon xenon 0 7月 6 19:16 ./ dr-xr-xr-x 8 xenon xenon 0 7月 6 19:16 ../ lrwx—— 1 xenon xenon 64 7月 6 19:17 0 -> /dev/pts/1 lrwx—— 1 xenon xenon 64 7月 6 19:17 1 -> /dev/pts/1 lrwx—— 1 xenon xenon 64 7月 6 19:16 2 -> /dev/pts/1 lr-x—— 1 xenon xenon 64 7月 6 19:17 3 -> /home/xenon/delete-me (deleted) /proc/4933/fd $ cat /proc/4933/fd/3 This is the data to be recovered~
- 1. rm 刪除命令
- 2. 6月26日
- 3. 1四、刪除命令--rm
- 4. rm 命令(刪除文件和目錄)
- 5. linux明日命令(6):rm命令
- 6. linux每日命令(6)：rm命令
- 7. Linux命令替換rm命令防止誤刪除
- 8. linux (rm指令) 及誤刪除解決
- 9. 3月26日
- 10. Linux系統中rm刪除命令
- 更多相關文章...
- • Docker rm 命令 - Docker命令大全
- • MySQL DELETE：刪除數據 - MySQL教程
- • Docker 清理命令
- • Flink 數據傳輸及反壓詳解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. rm 刪除命令
- 2. 6月26日
- 3. 1四、刪除命令--rm
- 4. rm 命令(刪除文件和目錄)
- 5. linux明日命令(6):rm命令
- 6. linux每日命令(6)：rm命令
- 7. Linux命令替換rm命令防止誤刪除
- 8. linux (rm指令) 及誤刪除解決
- 9. 3月26日
- 10. Linux系統中rm刪除命令
Pingback: 626技術故障的致歉信
低級失誤，rm 命令太不安全。
nod，就算是rm -i也不安全，那提示根本沒人去看。
建議： 要刪除文件的時候，先mv到固定路徑，觀察一段時間（我的建議一天左右），若是沒有問題再rm掉。其實就是相似回收站的機制。
另外，關於當即停機的事情。我的以爲當時應該當即中止對外服務（公網入口），由於咱們不清楚能恢復到什麼程度，因此應該直接拒絕用戶寫入更多的數據，這比提示「提交成功」可是轉眼就找不到本身提交的東西要好多了。可是MySQL實例不能中止，在文件打開的狀況下，不會真正刪除這個文件。直到全部句柄都關閉後這個文件才完全消失。
意識問題，另外還缺乏一個成熟的dba，若是有成熟的dba在，即便刪除了，也能夠恢復更多的數據。
咱們以前發生過把網站用戶註冊數據所有刪除的慘案，7000萬用戶，用drop table，從庫也執行了這條命令，沒有sql靜態文件備份，悲劇不少
立刻停機是正確的,防止文件被覆蓋。 停機後取下硬盤並用dd複製一份數據，全部操做在新硬盤上執行
若是你的分區是ext3，用ext3grep， +腳本批量處理一下，99.9%的數據能夠搶救回來
立刻停機在任何狀況下都是錯誤的。停機的決定應當在明白你在幹什麼時再作決定，只有直接致使問題的操做應當當即停止。誤刪除什麼的，意識到以後的第一反應應當是：哪些進程依舊打開了這個文件，若是有，當即從其文件描述符備份。
理論上是可行的,問題是: - 文件太多,沒法簡單的快速恢復 - 不是全部涉及文件有進程在打開
從內存copy文件很快的
立刻停機是徹底錯誤的，proc文件系統中有可恢復的數據，只要文件描述符沒被關閉。
很客觀的看待問題，而不是把全部的責任都拋給了那個輸錯rm的員工。這種錯誤也常常出現，備份纔是王道
雖然事故發生了。但我看到的一個高效，合做，高執行力的團隊。全力解決問題，利用各類手段，尋求外界幫助等等。很贊！ 不犯錯是不可能的，如何對待已經犯下的錯誤更重要。
萬幸。
> 4月23日，咱們把數據庫主節點遷移到一臺新的物理機上，並把版本升級到5.5。因爲版本和配置的問題，原來的從節點並不能直接使用。
4.23 的數據庫版本升級就應該主、備庫一塊兒升級，這應該是根本性的錯誤。 另外，在執行 rm -f 以前，哪怕是從節點，也最好作好備份操做。
Pingback: 數據丟失的進展
整個過程曲折啊，不過能恢復99%已經很是不錯了。 在看的過程當中想，若是是我遇到這樣的問題，我會這麼辦？貌似一點辦法都沒有。 由於上面提到不少術語不知道。。。
錯誤你們都會犯，關鍵仍是作好保護措施。
只能說，備份很關鍵，刪除數據庫分區，無論是用rm仍是drop table 都有認爲誤操做的可能性，再一個，重大更新時，須要兩我的協調確認
應付數據丟失的方式就是多存幾個備份。。
很奇怪，線上不是主從的架構麼？只是刪除主庫分區，任何一臺從庫數據都應該是ok的啊。
本身運維老是不免會由於缺少專業的各方法的人才而出現各類問題。 對創業者來說雲計算是一個很好的選擇。
測試環境，在系統或者重大升級以前把全部的系統和軟件的升級作一遍，並在測試環境中作好一切的工做，能夠順利升級生產環境，減小錯誤和對生產環境的影響。
沒想到，數據丟失的後果這麼可怕，能夠想見當時兄弟們在怎樣的心理壓力下工做，對技術團隊的士氣打擊估計也很嚴重。之後要引覺得戒，不能再對數據安全不覺得然了。另外我比較好奇，此次事故總共形成了多少經濟損失？那些數據恢復公司，不多是免費的吧。還有就是總共形成了多少間接損失？好比用戶流失之類的。有沒有相關數據披露？
看完整篇文章給個人感受就是：咱們很是牛B，雖然沒有備份，但仍然恢復了99.9%的數據
整篇文章徹底沒有總結出問題所在，下次確定還會犯錯誤
delete數據的那我的的責任只有5%，運維的責任有10%，管理的責任是85%
從4月23號就中止了備份，中間各類緣由沒有去備份，管理人員幹毛去了？大家不知道備份的重要性？還有什麼事情比備份重要？原本這下大家知道備份的重要了吧？結果只是增長一個雲備份，，下次你再有這種狀況，你仍是僅有2個月前的備份，還照樣扯蛋
增長雲備份也好，增長多臺服務器備份也好，這些只是細節， 最重要的是提升備份的優先級，象這種數據庫升級完成以後，備份沒作好這事兒就不算完，禁止使用，禁止上線，這纔是根源，不然下次還會被其它事情拖後，還會出問題
大家應該很慶幸，感謝那個delete的人，才2個月就出了事，絕對應該給那我的發獎金，不然按當前的態度下去，你一直不會有時間來作備份，一年以後再掛，哈哈哈哈，我就不信你還出說能恢復到90%？
#是也乎#沒法贊成更多…
Pingback: 「下廚房」技術團隊分析、總結6.26數據丟失事故 | r6
還好找回99%，吃一虧長一智。。。
我大約在6月份入侵了大家的系統獲取到了mysql的權限 而且作了一次dump
這部分數據我不知是不是有用的,能夠經過網盤分享給你
這個纔是最nb的啊。。。。。。
咱們也曾遇到過數據丟失的狀況，也是由於備份機制不完善。每每到數據丟失時才後悔莫及，多麼痛的領悟：（ 從搜索引擎的快照裏恢復頁面，咱們當時也這麼幹過。備份，備份，仍是備份！
「6月26日凌晨12點左右，咱們開始從新創建備份節點的工做，須要把原來的從節點刪除，從新安裝，因此先使用了rm -f方式刪除備份節點分區上的全部文件。」
暈倒，涉及數據庫的操做前居然不先作個備份，運維作的也太沒有章法了吧！
升級前備份，升級後備份，備份要保留n天。
值得警戒。
[via] CPyUG 的緬懷…. Re: [CPyUG] [OT]python寫的 下廚房 被黑了。 … 2013年7月6日下午7:10，金浩 寫道： > 能夠說說若是 rm -rf > 了一個文件，可是還有進程佔有這個文件句柄的狀況下，怎麼恢復剛剛被刪除的文件嗎？有沒有參考資料？我想在當時這種狀況下，若是開發人員知道這個技巧，恢復確定會比如今簡單的多，因此但願分享出來，給其餘開發人員萬一之後碰到相似的問題作個參考，謝謝！！！
剛纔試了下。。。
一個終端（記爲A）：
# [07/06 19:16:15] xenon@ribosome ~ $ touch delete-me # [07/06 19:16:22] xenon@ribosome ~ $ vim delete-me 寫進去一行字，做爲內容。
另外一個終端（記爲B）打開文件：
# [07/06 19:16:05] xenon@ribosome ~ $ python Python 2.7.5 (default, Jun 10 2013, 12:07:26) [GCC 4.7.3] on linux2 Type 「help」, 「copyright」, 「credits」 or 「license」 for more information. >>> fp = open(‘delete-me’) >>> fp
>>>
在A裏刪掉文件：
# [07/06 19:16:34] xenon@ribosome ~ $ rm delete-me rm：是否刪除普通文件 「delete-me」？y
找到剛纔的Python進程：
# [07/06 19:16:50] xenon@ribosome ~ $ ps -Af | grep python xenon 3285 3114 0 17:53 ? 00:00:01 /usr/bin/python2.7 /usr/bin/terminator xenon 4844 3114 0 19:16 ? 00:00:00 /usr/bin/python2.7 /usr/bin/terminator xenon 4933 4866 0 19:16 pts/1 00:00:00 /usr/bin/python2.7 xenon 4934 3114 1 19:16 ? 00:00:00 /usr/bin/python2.7 /usr/bin/terminator xenon 5070 4956 0 19:16 pts/2 00:00:00 grep –color=auto python
是4933，而後：
# [07/06 19:17:03] xenon@ribosome /proc/4933/fd $ ll /proc/4933/fd 總用量 0 dr-x—— 2 xenon xenon 0 7月 6 19:16 ./ dr-xr-xr-x 8 xenon xenon 0 7月 6 19:16 ../ lrwx—— 1 xenon xenon 64 7月 6 19:17 0 -> /dev/pts/1 lrwx—— 1 xenon xenon 64 7月 6 19:17 1 -> /dev/pts/1 lrwx—— 1 xenon xenon 64 7月 6 19:16 2 -> /dev/pts/1 lr-x—— 1 xenon xenon 64 7月 6 19:17 3 -> /home/xenon/delete-me (deleted) # [07/06 19:17:04] xenon@ribosome /proc/4933/fd $ cat /proc/4933/fd/3 This is data to be recovered~
嗯，啥都不須要
試驗過，這個方法真不錯。
執行操做的哥們意識到上錯機器後確定脊樑骨都涼了啊！
只能說，運維水平過低。 前面有很多說了的，我就不重複了。
首先，做業現場，做業實施者，有沒有再三確認本身的做業內容？確認本身所在機器？ 這個不是靠我的自覺或者我的技術水平，而是要明確寫在「做業計劃」「實施步驟」裏面。
第二，做業的時候，有沒有另一我的在旁邊看着？幫忙確認？ 若是沒有，也是不容許的。這種線上生產環境的做業，必定至少要求雙人做業。
Pingback: 如何從MySQL/InnoDB數據文件中的恢復數據 - 一個故事@MySQL DBA
備份最重要。就算是這個操做人員不會出錯，能保證其餘的人員不會操做出錯。
搞個集羣用mysql cluster吧，開3 replica
大傢什麼都不缺，就缺一個專業DBA，鑑定完畢
數據庫操做簡單，保證安全困難。像硬盤這些都是有壽命的。之後謹記每天備份，數據無價啊
1.hostname 2.backup
有MYSQL slave 節點 ，應該先升級salve 而後再master. 剩下的就是犯了低級錯誤了。
出了這樣事情的教訓就是弄個雲備份？ 看來尚未意識到問題出在哪裏