實際工作中,經常遇到一些臨時應急需求,DBA沒有充分準備之前,直接到線上執行一些命令,除此之外一些沒有考慮清楚厲害關系的命令,最后導致事故的情況。
MySQL DBA運維中那些動作屬于危險性操作?
MySQL數據庫操作:
1. shutdown/restart命令(8.0版本): 關閉 mysql服務,重新啟動,
- 平時在運行習慣,在測試環境隨意執行,到生產無意識執行這些命令。
- 大事務運行還沒結束,執行命令導致事務大量回滾 或 無法數據庫及時關閉問題。如load 等操作中
2. kill pid進程
不是馬上kill掉進程,底層要進行回滾動作,要是大事務 回滾需要很長時間 30分鐘,3個小時或更長。
- 碰到大事務下,kill操作
- 服務器負載過高,無法提供足夠的CPU,IO等資源
3. FLUSH BINARY LOGS:
截斷舊binlog日志,產生新的binlog日志,同事也會觸發expire_logs_days參數清除過期binlog,在高可用架構下禁止執行。
- 從庫因為其他問題,日志還有沒分發到從庫relay log中
- 正好進行大事務,截斷操作,可能導致,數據庫窮住。
binlog記錄的是數據操作記錄,被清除,在出現故障無法進行恢復
4. set sql_log_bin=0
SESSION操作不記錄binlog,當然一些特殊情況,不想分發到從庫,比如從庫要額外創建一些索引之類的。
- 相關操作無法分發到從庫上
5. RESET MASTER / RESET SLAVE :
重置主節點,從節點信息
- gtid重置,
- binlog 信息清除 或
- 重置復制信息
6. TRUNCATE TABLE
清除數據,
- 不會記錄binlog 恢復找到操作詳細數據
- 處置之外truncate 有一定的概率觸發bug ,窮住庫
7. DROP DATABASE
刪除數據和文件
- binlog 不會記錄詳細數據操作
- 底層數據和結構文件,全部物理刪除
8. FLUSH TABLES。。。(FLUSH TABLES WITH READ LOCK):
- 關閉所有打開的表
- 強制關閉所有正在使用的表
- 并刷新查詢緩存和預準備語句緩存
- 不會刷新臟塊
- 上全局COMMIT鎖
9. LOCK TABLES READ/WRITE ;
鎖表動作
10. ALTER DATABASE dbname READ ONLY(8.0版本)
對于數據庫只讀,不允許寫
11. slave_skip_errors :
跳過復制錯誤代碼,導致主從數據不一致
12. purge binary logs
清除binglog物理文件,復制狀態下,需要確保無用的binlog進行清除。
13. DML操作條件寫錯 或 不使用索引
- where 不使用索引,導致全表掃描
- insert into t1 select * from t2方式:t1 或 t2 表結構變化導致語句失敗。
14. 在線DDL
不管online ddl 還是 pt-osc ,gh-ost都會有一定的問題存在,所以謹慎執行,特別是高負載下。
- online ddl 導致meta data lock
- pt-osc 因為表數量大導致中間意外停止,觸發器無法刪除
- gh-ost binlog接受,延遲導致一直無法進行下去。
15. ANALYZE ,OPTIMIZE table
- 鎖表,緩存移除,對表數據無法進行修改,嚴重的話會影響業務。
15. MySQL無備份、無高可用節點,binlog沒有開啟(ROW)模式
- 故障觸發,一些操作 都無法回逆。這種環境更應該謹慎
16. 執行rm -rf / data tmp 等類似操作,執行rm 前要三思
- 物理刪除,進程在雖然可以通過lsof delete方式召回,但未必能全部恢復。
17. 不用mysqld_safe守護進程啟動, 執行kill mysqld pid 等操作
- 沒有守護進程,mysql服務器會異常關閉,無法啟動。更嚴重情況下數據文件損壞,無法啟動
18. 在生產環境執行測試命令。
19. 邏輯恢復數據,實例不對(基于IP連接管理環境)
- 特備是開發工具Navicat,SQLyog,這部分權限需要控制好。
- 執行數據操作命令需要核對實例信息
20. 空間不夠下的操作
導致導致事務丟失,文件損壞,比如備份,遷移數據文件等操作。
21. 從庫延遲并對外提供服務
數據延遲,導致業務段收到的信息不對。因為mysql是邏輯回放。
22. 開多窗口操作重要數據庫
容易把命令 分發到所有節點。
23. 敏感字段不加密,線上數據同步到線下
敏感數據無法做到透明,但可以通過一些函數算法,替換一些字段。
24. 系統表操作
對mysql庫 ,information_schema庫下的表進行刪除,更改,創建,truncate 動作,都有可能導致數據庫無法啟動。
25.參數更改
- lower_case_table_names大小寫敏感,只能初始化設置,之后不建議改。需要改動就邏輯導出導入方式
- innodb_buffer_pool_size 在線調整,當負載高的時候容易出現持續窮住現象。
26.犯困時操作線上環境
- 復雜操作需要制定好操作步驟
- 需要第二人協助確認和檢查
總結
雖然目前很多數據庫管理已經逐步進入半自動化,腳本化。但很多時候還需要人為操作,需謹慎。雖做到萬無一失很難,但做好備份,準備工作,環境允許甚至測試驗證都是必不可少的。
最后修改時間:2022-12-27 13:30:31
「喜歡這篇文章,您的關注和贊賞是給作者最好的鼓勵」
關注作者
【版權聲明】本文為墨天輪用戶原創內容,轉載時必須標注文章的來源(墨天輪),文章鏈接,文章作者等基本信息,否則作者和墨天輪有權追究責任。如果您發現墨天輪中有涉嫌抄襲或者侵權的內容,歡迎發送郵件至:contact@modb.pro進行舉報,并提供相關證據,一經查實,墨天輪將立刻刪除相關內容。




