實際工作中，經常遇到一些臨時應急需求，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.犯困時操作線上環境

• 復雜操作需要制定好操作步驟
• 需要第二人協助確認和檢查

總結

雖然目前很多數據庫管理已經逐步進入半自動化，腳本化。但很多時候還需要人為操作，需謹慎。雖做到萬無一失很難，但做好備份，準備工作，環境允許甚至測試驗證都是必不可少的。