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. 一定要嚴格按照步驟來進行操作。寧願延期，不要加戲。
７. 留幾個問題
2. 如果資料庫掛了，機器可以啟動但是 mysql 程序無法啟動，你這裡又有昨天的備份可以恢復，你該怎麼做？
3.想要刪庫完全不出問題，那麼刪庫流程該怎麼設計？
好了，公司還是要有自己的 db 產品，再簡陋也要有。
gitee 刪庫跑路的正確開啟方式
又是乙個周一,陽光一點都不明媚.碼雲 gitee.com 五群 qq群號 515965326 又發生了一起刪庫跑路事件 手動滑稽 手動部分截圖 為了更好的復現完整的流程,特意新建了乙個 gitee 倉庫,方便說明和復現 建立完成後新庫位址如下 點選 管理 選擇 刪除倉庫 操作 會出來乙個刪除倉庫彈窗...
差點刪庫跑路的一天
今天因為一條命令差點就把公司伺服器全清空了，就是下面這條命令 rm rf 哦豁，完蛋，敲完後命令列一直往下跳，一直翻頁，感覺不對勁，立刻把ssh斷開了，覺得還是不對，跑進機房把伺服器斷電 最後發現再也無法開機了，按照開機提示好像是說引導區已經被破壞掉，我一臉不安地去問下我們組資深的謝工，這才明白我剛...
oracle資料的閃回 刪庫跑路？老鐵別想了！
在公司某個黑暗的小角落，乙個初出茅廬的小夥子，拿到了剛剛交接的文件開始躍躍欲試，結果乙個drop開始了他的噩夢！這個時候凱哥在他背後猥瑣的笑了笑，捋了捋5年了還沒掉光的頭髮。一頓操作猛如虎！閃回技術是oracle強大資料庫備份恢復機制的一部分，在資料庫發生邏輯錯誤的時候，閃回技術能提供快速且最小損失...