總結這幾年運維工作中犯的錯
得知下廚房的數據被誤刪了，正在緊張恢復中。作為犯過很多次嚴重錯誤的人，我最想說的是，善待當事人吧，此刻他在承受著巨大的壓力，比其他任何人都要心焦，他會很感激你的善言和善意。
這幾年犯過很多次嚴重影響線上服務的錯誤，像重啟了錯誤的節點這樣的事情應該算作能夠對線上造成影響的最微不足道的錯誤，就只簡單說幾件現在都還讓我心有余悸的事吧。
停用線上 memcache 集群
在調整 memcache 客戶端配置的使用和部署方式之前，盡管經過了多次測試，比如在部分節點先上線，確認沒有問題之后上線所有的應用服務器，但還是使用了錯誤的配置，導致線上所有應用禁用了 memcache，巨大的訪問壓力瞬間拖垮了數據庫，從發現問題到完全恢復持續了將近二十分鐘。
軟件 bug 導致線上 memcache 集群被污染
上線的代碼在特定條件下會禁掉對 memcache 的使用，導致在本應清除 cache 的情況下沒有清除，污染了整個線上的 memcache 集群，后果是各處功能出現詭異的問題，比如提醒死也叉不掉… 不得不將整個 memcache 集群 flush 一遍消除影響，耗時半天。
恢復數據時刪除了更多數據
線上有豆列被誤刪了，從備份緊急恢復時，使用 mysqldump 導出需要恢復的那部分數據，但是遺憾的是連 DROP TABLE ... 也一起 dump 了，并且在線上執行之前都沒有意識到。結果，原本需要恢復的只是一個豆列，恢復之后只剩下了一個豆列，豆列功能緊急只讀，重新恢復數據并做數據合并…
數據庫主從切換時從庫還未跟上同步
我在給從庫熱身，準備切換主從，這時候有兩個不愿意透露姓名的同事來找我聊另外一件事情，很愉快地聊完，我愉快地發現已經熱身完了，于是愉快地用土腳本做了主從切換，然后悲劇地收到了報警，數據沖突同步中斷了，原來是熱身過程中從庫因為壓力比較高造成的滯后還未追平，而我已經愉快地做了切換。
誤操作并誤刪數據文件
在一次主從切換之后，我突然發現新的 slave 同步在繼續，但是 binlog 卻停止寫入了，之后驚訝地發現 master 上的 SQL_LOG_BIN 竟然是一個 global 級別的變量，并且值是 0。原來是之前在 slave 上調整索引時，本該 SET SQL_LOG_BIN=0，卻無意識地執行了 SET GLOBAL SQL_LOG_BIN=0，禁用了整個 slave 實例而不只是當前 session 的 binlog，主從切換之后，整個集群就只剩下了一個節點有完整的數據，在我發現并修復這個問題之前，新 slave 上已經缺失了 3 分鐘的數據。嘗試了各種方法，想要準確無誤地修復這 3 分鐘的數據還是挺有難度的，尤其是在承受巨大精神壓力的情況下，只好選擇了從 master 重建。然而在我備份完 master 節點，重建新 slave 時又誤刪了 slave 上的數據文件，這下更刺激了，在新的 slave 重建完成之前，如果 master 宕機，我就真的連一個可以應付線上壓力的節點都沒有了，哪怕是一個缺少了 3 分鐘數據的實例。
在發生這些事情時，真的是想死的心都有，支撐我的還有一個信念：無論如何把這個爛攤子收拾完了再死！而有過這樣的經歷，我就非常感激那些本來有絕對權利責難我，但在事情發生時立刻馬上挽起袖子和我一起解決問題，事后幫我一起想辦法如何避免這樣的問題再發生的人，比如不愿意透露姓名的 hongqn 和 flycondor。
經歷和看到過越多這樣的事情，我就越覺得犯錯是不可避免的，無論你思維有多縝密，行事有多謹慎，只要做事就無可避免地會犯錯誤，或大或小，甚至現在每隔一段時間發現自己沒有在線上犯錯誤，就會想：我最近在干嘛？
最后，備份不做，日子甭過，真的會有半夜鬼敲門，另外，作為 SA 或 DBA，真的需要確保每一個危險操作都至少是可以 rollback 到上一步的，并且在進行下一步操作之前，要確認所有已知狀態都是正常的，工具比人更擅長做這些事，人的精力應該花在讓這些工具更加可靠上。
注：最后一個問題涉及 MySQL 5.5 相對于之前版本的一個行為變化，參考：
原文鏈接：http://blog.xupeng.me/2013/06/27/mistakes-in-production-system-these-years/
