不小心刪庫是一種怎樣的體驗？半個DBA的跑路經(jīng)驗總結(jié)
最近這篇《不小心刪庫是一種怎樣的體驗？》比較火，蹭個熱度講講半個 DBA 的刪庫經(jīng)驗。
大半夜的腦子比較糊涂，簡單寫一寫。
部分內(nèi)容僅限于 mysql。
0. 國內(nèi)呆不下了，趕緊出國
首先，不要選動車，要選最近的一班飛機，盡快出國，能走高速走高速，不然選人少的路線。
沒錯，我們 DBA 都是常備護照的。
切記，注意看高德地圖實時路況。
我們有個前輩就是刪庫之后開車就上二環(huán)，下午五點鐘。警察到的時候他還堵在路上。
1. 只不過是把數(shù)據(jù)干掉了
權(quán)限問題永遠(yuǎn)是大問題，做好權(quán)限回收，開發(fā)數(shù)據(jù)庫和線上數(shù)據(jù)庫分離，線上數(shù)據(jù)庫管理權(quán)限（一般指修改表結(jié)構(gòu)權(quán)限與刪表權(quán)限）禁止回收，也不提供給業(yè)務(wù)直接用。
不然參考 0。
公司管理上，***有自己的 DB 運維產(chǎn)品，線上數(shù)據(jù)庫只允許查，改的話要有審批流程。
至于查數(shù)據(jù)要不要脫敏、導(dǎo)入導(dǎo)出流程，就看自己產(chǎn)品的規(guī)劃和排期了。
至于 DBA 怎么保證不手滑，這個每個人有每個人的習(xí)慣。
2. 刪庫什么的都是小 case
清理數(shù)據(jù)庫之前一定要檢查進程，是否存在數(shù)據(jù)庫進程，如果存在則寧愿不搞也不要深夜搞。
公司清理數(shù)據(jù)庫要有下線流程。下線一定要走流程。寧愿多租幾天機房也不要丟掉數(shù)據(jù)。
不然參考 0。
原則是：
rm 文件之前先檢查進程是否存在。
絕不手工 drop 庫表，如果非要 drop，則應(yīng)該寫成 rename，truncate 也是類似，寫成 rename 和 create table like 兩條 sql。
刪表之前可以根據(jù)表文件的***修改時間進行再次確認(rèn)，不確認(rèn)就找人 review，有下線流程則走下線流程。
3. 備份，備份，備在何處？
冷備，熱備都要有，一定要每天一備。
冷備便是應(yīng)對這種情況。
公司應(yīng)該有自己的 DB 備份方案，并且保證執(zhí)行到位。
４. 人算不如天算
關(guān)于這一點，可以單獨拉一個大專題出來了，核心內(nèi)容是 mysql 高可用。
簡單起見，推薦這篇文章：避免硬件故障的核心解決方案是冗余。
硬件層面的 raid，軟件層面的主從、熱備都是為了保證某一個節(jié)點宕機，其他節(jié)點仍然能繼續(xù)工作。
所有庫都要有主從備份，一方面做讀寫分離，一方面也是為了備份、高可用。
即便有半同步復(fù)制，有些極端情況下可以認(rèn)為，mysql binlog 沒有同步到從庫上，仍然可能存在 binlog 丟失（數(shù)據(jù)丟失）的風(fēng)險。
所以應(yīng)對這點，比較好的開源解決方案有 2：TiDB 和 Mysql GR。
5. 升級也能失?。?/strong>
說起來很簡單，升級無非是：
準(zhǔn)備升級
過程原理
手工升級后拓?fù)洌?/p>
工具（mha）升級后拓?fù)洌?/p>
6. 操作之前有個流程
一般自己操作的時候，都不會有太多的顧忌。
但是要是拿給別人看，就要考慮一下了。
如果別人不只要看，還要 review，那這樣就比較難犯重大的錯誤了。
如果有些操作需要夜間一個人搞，那么一定要提前列好準(zhǔn)備，這個就比較正式了。
包括：
1. 梳理具體的執(zhí)行步驟、執(zhí)行命令和每個步驟的預(yù)計結(jié)果。
2. 如果某些步驟出錯，是否要求回滾、預(yù)先制定回滾方案。
3. 詳細(xì)記錄執(zhí)行記錄，每一步都要有反饋。
4. 事先梳理好收尾工作。
5. 強關(guān)聯(lián)業(yè)務(wù)要事先通知，考慮到時間段和別的業(yè)務(wù)高峰，盡量讓對方也安排人留守觀察。
6. 一定要嚴(yán)格按照步驟來進行操作。寧愿延期，不要加戲。
７. 留幾個問題
1. 如果你有機會進行 mysql 遷移和升級工作，你認(rèn)為無法寫入數(shù)據(jù)造成的影響大，還是寫入臟數(shù)據(jù)造成的影響大？
2. 如果數(shù)據(jù)庫掛了，機器可以啟動但是 mysql 進程無法啟動，你這里又有昨天的備份可以恢復(fù)，你該怎么做？
3.想要刪庫完全不出問題，那么刪庫流程該怎么設(shè)計？
好了，公司還是要有自己的 DB 產(chǎn)品，再簡陋也要有。
