摘要：最近這篇不小心刪庫是一種怎樣的體驗比較火，蹭個熱度講講半個的刪庫經驗。下線一定要走流程。冷備便是應對這種情況。公司應該有自己的備份方案，并且保證執(zhí)行到位。包括梳理具體的執(zhí)行步驟執(zhí)行命令和每個步驟的預計結果。寧愿延期，不要加戲。

最近這篇《不小心刪庫是一種怎樣的體驗？》
（https://www.zhihu.com/questio...）比較火，蹭個熱度講講半個DBA的刪庫經驗。

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

部分內容僅限于mysql。

首先，不要選動車，要選最近的一班飛機，盡快出國，能走高速走高速，不然選人少的路線。
沒錯，我們DBA都是常備護照的。
切記，注意看高德地圖實時路況。
我們有個前輩就是刪庫之后開車就上二環(huán)，下午五點鐘。警察到的時候他還堵在路上。

權限問題永遠是大問題，做好權限回收，開發(fā)數(shù)據(jù)庫和線上數(shù)據(jù)庫分離，線上數(shù)據(jù)庫管理權限（一般指修改表結構權限與刪表權限）禁止回收，也不提供給業(yè)務直接用。

不然參考0。

公司管理上，最好有自己的DB運維產品，線上數(shù)據(jù)庫只允許查，改的話要有審批流程。至于查數(shù)據(jù)要不要脫敏、導入導出流程，就看自己產品的規(guī)劃和排期了。

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

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

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

不然參考0。

原則是：

rm文件之前先檢查進程是否存在。

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

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

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

冷備便是應對這種情況。

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

關于這一點，可以多帶帶拉一個大專題出來了，核心內容是mysql高可用。

簡單起見，推薦這篇文章：

避免硬件故障的核心解決方案是冗余。
硬件層面的raid，軟件層面的主從、熱備都是為了保證某一個節(jié)點宕機，其他節(jié)點仍然能繼續(xù)工作。
所有庫都要有主從備份，一方面做讀寫分離，一方面也是為了備份、高可用。

即便有半同步復制，有些極端情況下可以認為，mysql binlog沒有同步到從庫上，仍然可能存在binlog丟失（數(shù)據(jù)丟失）的風險。
所以應對這點，比較好的開源解決方案有2：TiDB和Mysql GR。

說起來很簡單，升級無非是：

準備升級：

過程原理：

手工升級后拓撲：

工具（mha）升級后拓撲：

一般自己操作的時候，都不會有太多的顧忌。
但是要是拿給別人看，就要考慮一下了。
如果別人不只要看，還要review，那這樣就比較難犯重大的錯誤了。

如果有些操作需要夜間一個人搞，那么一定要提前列好準備，這個就比較正式了。

包括：

梳理具體的執(zhí)行步驟、執(zhí)行命令和每個步驟的預計結果。

如果某些步驟出錯，是否要求回滾、預先制定回滾方案。

詳細記錄執(zhí)行記錄，每一步都要有反饋。

事先梳理好收尾工作。

強關聯(lián)業(yè)務要事先通知，考慮到時間段和別的業(yè)務高峰，盡量讓對方也安排人留守觀察。

一定要嚴格按照步驟來進行操作。寧愿延期，不要加戲。

如果你有機會進行mysql遷移和升級工作，你認為無法寫入數(shù)據(jù)造成的影響大，還是寫入臟數(shù)據(jù)造成的影響大？

如果數(shù)據(jù)庫掛了，機器可以啟動但是mysql進程無法啟動，你這里又有昨天的備份可以恢復，你該怎么做？

想要刪庫完全不出問題，那么刪庫流程該怎么設計？

好了，公司還是要有自己的DB產品，再簡陋也要有。