最近這篇《不小心刪庫是一種怎樣的體驗(yàn)？》比較火，蹭個熱度講講半個 DBA 的刪庫經(jīng)驗(yàn)。

大半夜的腦子比較糊涂，簡單寫一寫。

部分內(nèi)容僅限于 mysql。

0. 國內(nèi)呆不下了，趕緊出國

首先，不要選動車，要選最近的一班飛機(jī)，盡快出國，能走高速走高速，不然選人少的路線。

沒錯，我們 DBA 都是常備護(hù)照的。

切記，注意看高德地圖實(shí)時路況。

我們有個前輩就是刪庫之后開車就上二環(huán)，下午五點(diǎ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 運(yùn)維產(chǎn)品，線上數(shù)據(jù)庫只允許查，改的話要有審批流程。

至于查數(shù)據(jù)要不要脫敏、導(dǎo)入導(dǎo)出流程，就看自己產(chǎn)品的規(guī)劃和排期了。

至于 DBA 怎么保證不手滑，這個每個人有每個人的習(xí)慣。

2. 刪庫什么的都是小 case

清理數(shù)據(jù)庫之前一定要檢查進(jìn)程，是否存在數(shù)據(jù)庫進(jìn)程，如果存在則寧愿不搞也不要深夜搞。

公司清理數(shù)據(jù)庫要有下線流程。下線一定要走流程。寧愿多租幾天機(jī)房也不要丟掉數(shù)據(jù)。

不然參考 0。

原則是：

rm 文件之前先檢查進(jìn)程是否存在。

絕不手工 drop 庫表，如果非要 drop，則應(yīng)該寫成 rename，truncate 也是類似，寫成 rename 和 create table like 兩條 sql。

刪表之前可以根據(jù)表文件的***修改時間進(jìn)行再次確認(rèn)，不確認(rèn)就找人 review，有下線流程則走下線流程。

3. 備份，備份，備在何處？

冷備，熱備都要有，一定要每天一備。

冷備便是應(yīng)對這種情況。

公司應(yīng)該有自己的 DB 備份方案，并且保證執(zhí)行到位。

４. 人算不如天算

關(guān)于這一點(diǎn)，可以單獨(dú)拉一個大專題出來了，核心內(nèi)容是 mysql 高可用。

簡單起見，推薦這篇文章：避免硬件故障的核心解決方案是冗余。

硬件層面的 raid，軟件層面的主從、熱備都是為了保證某一個節(jié)點(diǎn)宕機(jī)，其他節(jié)點(diǎn)仍然能繼續(xù)工作。

所有庫都要有主從備份，一方面做讀寫分離，一方面也是為了備份、高可用。

即便有半同步復(fù)制，有些極端情況下可以認(rèn)為，mysql binlog 沒有同步到從庫上，仍然可能存在 binlog 丟失（數(shù)據(jù)丟失）的風(fēng)險(xiǎn)。

所以應(yīng)對這點(diǎn)，比較好的開源解決方案有 2：TiDB 和 Mysql GR。

5. 升級也能失?。?/strong>