大家好我是迷途，一個在互聯網行業，摸爬滾打的學子。熱愛學習，熱愛代碼，熱愛技術。熱愛互聯網的一切。無論你是正在路上的旅人，還是背上行囊，整裝待發的學子。 都可以點贊關注一下帥途的動態 當然如果帥途拿到比較好的學習資料或者看見比較好的文章也會第一時間跟大家分享。
前言
記錄一次帥途週末加班，由於自己的誤操作，把公司數據庫幹掉的慘痛經歷，本文內容背景完全真實，爲了保護隱私，文中人名用字母替代。
注意：由於本文操作內容過於危險，請各位小夥伴千萬不要模仿！！！
背景
帥途目前就職於一家賽事服務公司，公司不算太大，但是在業內也算小有名氣。主要從事b2b2c方面的賽事系統，和用戶系統的開發。由於庚子鼠年開頭受到新冠病毒影響，體育賽事行業受到前所未有的衝擊。公司開始全力發展線上業務。帥途也被抽調去了線上組，全力開發線上業務。一切就從這裏展開~
正文
起因
2020年5月24日清晨，陽光溫柔的灑在臉上，鳥兒在樹上跳着舞。房間裏躺着一個穿着短褲短袖睡得四仰八叉的年輕人，多麼美好的假期。這時年輕人放在牀頭櫃上的手機嘟嘟嘟的響了起來，年輕人迷迷糊糊拿起手機一看，原來是產品經理G打來的電話。
年輕人迷迷糊糊的接起電話，已經習以爲常的問了一句：“又是那個客戶在瞎搞了？又要改什麼東西。”
G說到：“有個主辦方，把賽事積分配錯了，你看你那邊能不能幫忙處理一下？”
年輕人無奈道：“運營那邊怎麼搞得，這都多少個了。天天這樣”
G又說到：“你趕快處理一下吧，就是XX體育局那個主辦方，上面領導挺重視的。”
年輕人無奈坐起身，跑到廚房拿了一盒牛奶，然後走到書房打開電腦，連接teamViewer。
無奈的想到，自從加入被抽調到線上業務，已經記不得這是多少次緊急處理問題了。好懷念以前做B端系統的時候，那用考慮什麼用戶環境，版本號，併發。還不用隨時隨地處理問題，現在搞得，放假手機24小時關注，出去玩電腦都得隨時帶着，就差跟段子裏一樣坐着地鐵，公司一個電話打來，直接在地鐵上擼代碼了。
年輕人連好遠程，給G發了個消息問道：“積分怎麼處理？”
G回到：“他們之前的用戶報名贈送積分配置錯了，現在他們賽事還沒開始，你先統一把積分處理成xx就好了”
“算了偷個懶，不寫代碼處理了，直接數據庫處理算了，反正就一個update，又沒多大事”年輕人心裏想着。（各位小夥伴，一定不要偷懶！帥途這是血與淚的教訓，就放在眼前！就算要偷懶也一定記得在測試環境先測試一邊sql，無論多簡單。然後正式庫執行的時候一定要先start transaction ;開啓事務！另外 一定要備份！要備份! backups！）
年輕人給G回了個消息：“好的，處理完了，我叫你。”
驚魂開始
年輕連上電腦之後，熟練的打開navicat，打開了塵封多年的代碼小本本，找到了公司的數據庫root賬號。
登錄了root賬號之後，想了一下，改個積分簡單~找到主辦方id，然後把積分修改了就好了，我還能繼續回去補個回籠覺。在夢裏還能繼續跟新來的UI小姐姐一起牽着手去逛街。。。
花了10秒鐘，寫出了update語句，簡直不要太easy
// 就是這一行罪惡的sql，在用戶報名記錄表中修改主辦方id爲10的用戶的積分爲50.
// 然後帥途居然把where給寫掉了，對 你沒有看錯！寫掉了！！！！！
update m_apply_record set sponsor_id=10,integral=50
點擊運行，“去冰箱拿個麪包來吃，剛睡醒就喝了個牛奶，餓死了。”年輕人心裏想着。
年輕人拿完麪包回來，看了一下剛剛執行的結果，瞬間如臨深淵。手上拿着的麪包掉在地上也渾然不知，5月的豔陽天，年輕人卻冒了一身冷汗，哪一個瞬間，背上的汗水就溼透了衣服。腦海裏想着，完了，300萬用戶數據，全炸了。我明天是不是會上新聞頭條，會不會被csdn首頁置頂，成爲各位小夥伴口中又一位刪庫跑路的勇士。
解決
在短短一分鐘時間裏，年輕人彷彿經歷了一場激烈的大戰。像是一口氣狂奔了五公里，又或者是坐着朋友開的車在擁堵的城市道路開着200碼。渾身冷汗直流，顫抖不止。
回過神來的年輕人，立馬反應過來，現在不是想這些的時候，怎麼解決纔是王道。
我剛纔有備份嗎？
沒有，剛剛就一個很簡單的操作，沒有備份。最近的備份是頭一天凌晨4點備份前一天的數據。
能回滾嗎？
不行，我剛纔沒有開啓事務，而且又是navicat工具執行，無法回滾
mysql日誌打開了嗎？
打開了！可以搶救，不要慌，先想解決方案。
果不其然，大約過了5分鐘之後，產品經理G打來電話，問道：“怎麼回事，怎麼線上所有正在進行的賽事都用不了了？”
年輕人面色沉靜道：“看見了，剛剛改數據出了點小問題，你不要慌5分鐘解決。”
ps(其實這裏帥途內心，非常慌張，咳咳！但是絕對不能讓他們發現異樣，不然先不說項目獎金之類的還有沒有，估計還得先考慮是不是真的要跑路了。這裏得心態有點像，每次測試組小姐姐提bug的時候，嘴上特別硬氣，唉你是不是又誤操作了，是不是環境又不對，然後自己偷偷摸摸把bug修復了。)
掛斷電話之後，年輕人腦海裏面立馬浮現出一套解決方案，如果我現在直接用mysql的bin_log恢復數據的話起碼要一小時以上，況且這麼大數據量的情況下不可能快速解決。
現在數據全是亂的，用戶根本沒有辦法正常操作，那就只有最後一個辦法了，切庫！還好當初無聊的時候跟運維J要了咋門服務器的賬號密碼，有時候也會幫他看看問題bug之類的，說幹就幹，年輕人立馬打開idea，修改配置文件，將數據庫切換到備份庫，打包，6臺服務器6個節點，大概花了7-8分鐘，刷刷刷，搞定~
年輕人弄完這些之後，給G發了一條微信消息：“搞定了，不過這邊顯示可能出了個小問題，有些用戶數據展示不正常，我正在處理，現在賽事能正常使用了~”（哪裏是什麼小問題，差點把帥途給嚇死，不過表面功夫還是得過得去，作爲和測試產品周旋多年的江湖大蝦，波瀾不驚是最基本得素養。）
做完這一切之後，年輕人默默開始用sqlbin恢復數據。
-- 查看當前所有binlog日誌
show master logs;
-- 查看當前日誌記錄動作
show binlog events in 'mysql-bin.000003';
然後再我們Linux上面導出我們執行誤操作的日誌文件，一般來說都是最後一個日誌。
-- 導出日誌文件
/usr/bin/mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000003 > /logs/mysqlLogs/1.sql
根據end_pos恢復到某一個節點
-- 根據end_pos恢復據 在Linux執行
/usr/bin/mysqlbinlog --stop-position=32314 --database=goteam_test /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v goteam_test
-- 解析版
#{mysqlbinlog} --stop-position=#{end_pos} --database=#{數據庫名稱} #{日誌文件位置} | /#{mysql數據庫所在位置} -u#{賬號} -p#{密碼} -v #{數據庫}
例如：我們要恢復到當前這個表中update語句執行之前，我們可以在Linux上執行命令
-- 根據end_pos恢復據 在Linux執行
/usr/bin/mysqlbinlog --stop-position=9960 --database=goteam_test /var/lib/mysql/mysql-bin.000001 | /usr/bin/mysql -uroot -p123456 -v goteam_test
根據時間節點恢復數據
-- 根據時間恢復
/usr/bin/mysqlbinlog --stop-datetime='2020-05-11 16:28:05' --database=goteam_test /var/lib/mysql/mysql-bin.000001 | /usr/bin/mysql -uroot -p123456 -v goteam_test
-- 恢復中間某一段時間數據
/usr/bin/mysqlbinlog --start-datetime="2020-05-10 16:28:05" --stop-datetime="2020-05-10 20:58:18" --database=goteam_test /var/lib/mysql/mysql-bin.000001 | /usr/bin/mysql -uroot -p8856769abcd -v goteam_test
參考鏈接：程序員保命技能，Mysql bin_log數據恢復，你還不知道嗎？
結語
帥途在這裏總結一下本次經歷，一直到現在，帥途的心境都可以用4個字來形容，那就是驚魂未定！其實帥途這兩天也諮詢了身邊不少朋友，從十幾個人的小公司leader到某BAT大廠的開發，運維崗，同學、朋友，幾乎每一個人都有過或多或少的刪庫也好，錯改數據也好的經歷，只是可能每個人的處理方案造成的損失大於小罷了。無論你是開發十幾年大佬，還是初入江湖的開發新秀，亦或者身處學堂的莘莘學子，希望你們千萬不要像帥途一樣粗心大意，爲了圖省事，偷個懶。搞到最後雖然解決了問題，但是這個月的績效和獎金也一起被解決了。當然也要學好壓箱底的招數傍身，畢竟中國有句古話“不怕一萬，就怕萬一”嘛。
如果各位小夥伴真的迫不得已一定要對正式環境的數據進行操作，那麼在照做之前，一定要問自己幾個問題：
- 我必須要直接對正式環境進行操作？
- 我是否有備份？
- 我是否在測試環境測試過執行結果？
- 如果遇到不可控原因照成數據錯誤，我是否能很快處理？
最後帥途在這裏祝各位小夥伴永遠不會刪庫，代碼運行一次成功，產品經理永遠不會改需求，甲方爸爸都聽你的~
看到這了就快點贊關注一下吧