天天看點

順豐被删庫?半個DBA的跑路經驗總結

最近順豐又搞出一個熱門:

運維誤删庫事件!
順豐被删庫?半個DBA的跑路經驗總結
看看有沒有什麼後路好走啊哥們~ 0. 國内呆不下了,趕緊出國

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

沒錯,我們 DBA 都是常備護照的。

切記,注意看高德地圖實時路況。

我們有個前輩就是删庫之後開車就上二環,下午五點鐘。警察到的時候他還堵在路上。

1. 隻不過是把資料幹掉了
順豐被删庫?半個DBA的跑路經驗總結

權限問題永遠是大問題,做好權限回收,開發資料庫和線上資料庫分離,線上資料庫管理權限(一般指修改表結構權限與删表權限)禁止回收,也不提供給業務直接用。

不然參考 0。

公司管理上,最好有自己的 DB 運維産品,線上資料庫隻允許查,改的話要有審批流程。

至于查資料要不要脫敏、導入導出流程,就看自己産品的規劃和排期了。

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

2. 删庫什麼的都是小 case
順豐被删庫?半個DBA的跑路經驗總結

清理資料庫之前一定要檢查程序,是否存在資料庫程序,如果存在則甯願不搞也不要深夜搞。

公司清理資料庫要有下線流程。下線一定要走流程。甯願多租幾天機房也不要丢掉資料。

原則是:

rm 檔案之前先檢查程序是否存在。

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

删表之前可以根據表檔案的最後修改時間進行再次确認,不确認就找人 review,有下線流程則走下線流程。

3. 備份,備份,備在何處?
順豐被删庫?半個DBA的跑路經驗總結

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

冷備便是應對這種情況。

公司應該有自己的 DB 備份方案,并且保證執行到位。

4. 人算不如天算
順豐被删庫?半個DBA的跑路經驗總結

關于這一點,可以單獨拉一個大專題出來了,核心内容是 mysql 高可用。

簡單起見,推薦這篇文章:避免硬體故障的核心解決方案是備援。

順豐被删庫?半個DBA的跑路經驗總結

硬體層面的 raid,軟體層面的主從、熱備都是為了保證某一個節點當機,其他節點仍然能繼續工作。

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

即便有半同步複制,有些極端情況下可以認為,mysql binlog 沒有同步到從庫上,仍然可能存在 binlog 丢失(資料丢失)的風險。

是以應對這點,比較好的開源解決方案有 2:TiDB 和 Mysql GR。

5. 更新也能失敗?
順豐被删庫?半個DBA的跑路經驗總結

說起來很簡單,更新無非是:

準備更新

順豐被删庫?半個DBA的跑路經驗總結

過程原理

順豐被删庫?半個DBA的跑路經驗總結

手工更新後拓撲:

順豐被删庫?半個DBA的跑路經驗總結

工具(mha)更新後拓撲:

順豐被删庫?半個DBA的跑路經驗總結
6. 操作之前有個流程

一般自己操作的時候,都不會有太多的顧忌。

但是要是拿給别人看,就要考慮一下了。

如果别人不隻要看,還要 review,那這樣就比較難犯重大的錯誤了。

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

包括:

1. 梳理具體的執行步驟、執行指令和每個步驟的預計結果。

2. 如果某些步驟出錯,是否要求復原、預先制定復原方案。

3. 詳細記錄執行記錄,每一步都要有回報。

4. 事先梳理好收尾工作。

5. 強關聯業務要事先通知,考慮到時間段和别的業務高峰,盡量讓對方也安排人留守觀察。

6. 一定要嚴格按照步驟來進行操作。甯願延期,不要加戲。

7. 留幾個問題

1. 如果你有機會進行 mysql 遷移和更新工作,你認為無法寫入資料造成的影響大,還是寫入髒資料造成的影響大?

2. 如果資料庫挂了,機器可以啟動但是 mysql 程序無法啟動,你這裡又有昨天的備份可以恢複,你該怎麼做?

3.想要删庫完全不出問題,那麼删庫流程該怎麼設計?

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