0. 國內呆不下了，趕緊出國
首先，不要選動車，要選最近的一班飛機，儘快出國，能走高速走高速，不然選人少的路線。
沒錯，我們 DBA 都是常備護照的。
切記，注意看高德地圖實時路況。
我們有個前輩就是刪庫之後開車就上二環，下午五點鐘。警察到的時候他還堵在路上。
1. 只不過是把數據幹掉了
權限問題永遠是大問題，做好權限回收，開發數據庫和線上數據庫分離，線上數據庫管理權限（一般指修改表結構權限與刪表權限）禁止回收，也不提供給業務直接用。
不然參考 0。
公司管理上，最好有自己的 DB 運維產品，線上數據庫只允許查，改的話要有審批流程。
至於查數據要不要脫敏、導入導出流程，就看自己產品的規劃和排期了。
至於 DBA 怎麼保證不手滑，這個每個人有每個人的習慣。
2. 刪庫什麼的都是小 case
清理數據庫之前一定要檢查進程，是否存在數據庫進程，如果存在則寧願不搞也不要深夜搞。
公司清理數據庫要有下線流程。下線一定要走流程。寧願多租幾天機房也不要丟掉數據。
不然參考 0。
原則是：
rm 文件之前先檢查進程是否存在。
絕不手工 drop 庫表，如果非要 drop，則應該寫成 rename，truncate 也是類似，寫成 rename 和 create table like 兩條 sql。
刪表之前可以根據表文件的最後修改時間進行再次確認，不確認就找人 review，有下線流程則走下線流程。
3. 備份，備份，備在何處？
冷備，熱備都要有，一定要每天一備。
冷備便是應對這種情況。
公司應該有自己的 DB 備份方案，並且保證執行到位。
４. 人算不如天算
關於這一點，可以單獨拉一個大專題出來了，核心內容是 mysql 高可用。
簡單起見，推薦這篇文章：避免硬件故障的核心解決方案是冗餘。
硬件層面的 raid，軟件層面的主從、熱備都是為了保證某一個節點宕機，其他節點仍然能繼續工作。
所有庫都要有主從備份，一方面做讀寫分離，一方面也是為了備份、高可用。
即便有半同步複製，有些極端情況下可以認為，mysql binlog 沒有同步到從庫上，仍然可能存在 binlog 丟失（數據丟失）的風險。所以應對這點，比較好的開源解決方案有 2：TiDB 和 Mysql GR。5. 升級也能失敗？
說起來很簡單，升級無非是：準備升級
過程原理
手工升級後拓補
工具（mha）升級後拓撲
6. 操作之前有個流程
一般自己操作的時候，都不會有太多的顧忌。
但是要是拿給別人看，就要考慮一下了。
如果別人不只要看，還要 review，那這樣就比較難犯重大的錯誤了。
如果有些操作需要夜間一個人搞，那麼一定要提前列好準備，這個就比較正式了。
包括：
1. 梳理具體的執行步驟、執行命令和每個步驟的預計結果。
2. 如果某些步驟出錯，是否要求回滾、預先制定回滾方案。
3. 詳細記錄執行記錄，每一步都要有反饋。
4. 事先梳理好收尾工作。
5. 強關聯業務要事先通知，考慮到時間段和別的業務高峰，儘量讓對方也安排人留守觀察。
6. 一定要嚴格按照步驟來進行操作。寧願延期，不要加戲。
閱讀更多 IT界的菜鳥 的文章
