解決MySQL執行個體空間滿自動鎖定的問題 - ApsaraDB RDS

當RDS MySQL執行個體因慢SQL、插入資料過多等原因導致磁碟空間滿時，系統會自動鎖定執行個體以避免資料丟失（執行個體狀態為“鎖定中”）。鎖定後，執行個體將無法進行寫入操作。本文介紹如何清理資料檔案、臨時檔案、Binlog檔案、undo檔案和general_log檔案，解決儲存空間問題。

常見原因

以下是可能導致執行個體空間滿的主要原因：

資料檔案佔用過高：資料檔案佔用了大量磁碟空間。
記錄檔佔用過高：未正確設定記錄備份策略時，大事務SQL可能導致日誌快速增長。
臨時檔案佔用過高：查詢語句的排序、分組或關聯表產生的暫存資料表檔案，以及大事務未提交前的日誌快取檔案，可能導致臨時檔案佔用過高。
系統檔案佔用過高：undo檔案過大是主要原因之一。當InnoDB表存在長時間未完成的查詢語句，且查詢過程中表資料變化較大時，系統會產生大量undo資訊，佔用大量儲存空間。RDS MySQL 8.0會自動清理undo檔案，通常不會出現此類問題，但仍需關注特殊情況。
general_log檔案佔用過高：開啟general_log後，該檔案記錄了所有操作，包括每條SQL語句的執行細節。當訪問量較大或長時間未清理時，該檔案可能佔用大量儲存空間。您可以通過如下方法確認general_log檔案大小。
1. 查看執行個體儲存空間使用量，判斷sys_data_size檔案是否過大。
2. 查看執行個體是否已開啟general_log（運行參數值為ON）。
3. 串連RDS MySQL執行個體並執行如下語句，查詢general_log檔案大小：
```
SELECT table_schema AS '資料庫', table_name,SUM(data_length + index_length + data_free)/1024/1024 AS "表大小MB",SUM(DATA_FREE)/1024/1024 AS "片段大小MB"
FROM information_schema.TABLES
WHERE table_name='general_log'
```
  說明
  - 上述SQL會從information_schema資料庫的TABLES表中檢索mysql.general_log表的資料，並將其轉換為以MB為單位的大小。
  - 上述SQL擷取的資料為抽樣資料，與實際資料可能存在一定誤差。

解決辦法

您可按照以下步驟定位問題，並解決RDS MySQL執行個體因儲存空間不足導致的鎖定問題。

訪問RDS執行個體列表，在上方選擇地區，然後單擊目標執行個體ID。
在左側導覽列中單擊監控與警示，查看佔用儲存空間的檔案類型。
選擇對應的解決方案：
說明
磁碟空間清理後，通常需要等待5~15分鐘左右，RDS執行個體才會解鎖。