刪庫？半個DBA的跑路經驗總結

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. 必定要嚴格按照步驟來進行操做。寧願延期，不要加戲。

７. 留幾個問題

1. 若是你有機會進行 mysql 遷移和升級工做，你認爲沒法寫入數據形成的影響大，仍是寫入髒數據形成的影響大？

2. 若是數據庫掛了，機器能夠啓動可是 mysql 進程沒法啓動，你這裏又有昨天的備份能夠恢復，你該怎麼作？

3.想要刪庫徹底不出問題，那麼刪庫流程該怎麼設計？

好了，公司仍是要有本身的 DB 產品，再簡陋也要有。