解決RDS MySQL系統檔案過大導致儲存空間滿 - ApsaraDB RDS

RDS MySQL執行個體系統檔案（主要是undo檔案）過大，使儲存空間佔滿，導致執行個體自動鎖定時，您可以參照本文的指引來解鎖並清理undo檔案。

問題描述

RDS MySQL執行個體儲存空間滿，執行個體運行狀態為鎖定中。在監控與警示中，查看執行個體儲存空間使用量，undo檔案過大。

問題原因

系統檔案過大主要是由於undo檔案過大。當存在對InnoDB表長時間不結束的查詢語句，而且在查詢過程中表有大量的資料變化時，系統會產生大量的undo資訊，佔用大量儲存空間，導致儲存空間耗盡。為避免資料丟失，RDS會自動鎖定執行個體，執行個體運行狀態顯示為鎖定中。

說明

對於RDS MySQL 8.0，系統會自動清理undo檔案，不會出現此問題。

解決方案

步驟一：解鎖執行個體

擴容執行個體儲存空間後可解鎖執行個體。擴容儲存空間的詳細操作請參見變更配置。

步驟二：清理undo檔案

對於RDS MySQL 5.7：
串連RDS MySQL執行個體並執行如下語句，查詢innodb_undo_tablespaces參數的值。如何串連執行個體，請參見串連RDS MySQL執行個體。
```
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';
```
- 當innodb_undo_tablespaces取值為2時，表示執行個體允許使用獨立的undo資料表空間儲存undo資料，可以進行清理。
  當undo檔案大小超過innodb_max_undo_log_size參數值且其中的日誌不再被任何活動的事務所需要時，系統會對undo檔案進行truncate操作，清理過大的檔案並釋放空間。如何開啟參數，請參見設定執行個體參數。
  說明
  innodb_undo_tablespaces參數只能在執行個體建立時指定，建立後不再允許修改。因此對於早期已建立的RDS MySQL 5.7執行個體，由於建立時未指定，此時若innodb_undo_tablespaces=0則無法通過升級核心小版本切換到獨立undo資料表空間模式。
- 當innodb_undo_tablespaces取值為0時，表示不使用獨立的undo資料表空間，undo檔案儲存體在系統資料表空間ibdata1中，不可以進行清理。
  如果您希望清理這部分資料，您可以建立新的執行個體並遷移資料，或者將執行個體升級至RDS MySQL 8.0版本。詳細操作請參見升級資料庫版本。
  重要
  - 升級資料庫版本可能存在相容性問題，請仔細閱讀升級資料庫版本中的功能限制和版本差異。
  - 資料庫遷移或升級過程中，RDS會進行執行個體切換，請您盡量在業務低峰期執行遷移或升級操作，並確保您的應用有自動重連機制。執行個體切換的影響請參見執行個體切換的影響。
對於RDS MySQL 5.5、5.6，不支援清理undo檔案，建議將執行個體升級至RDS MySQL 5.7、8.0版本。詳細操作請參見升級資料庫版本。
如果您計劃將執行個體升級至RDS MySQL 5.7版本時，請選擇高可用系列。該系列的innodb_undo_tablespaces取值為2，允許使用獨立的undo資料表空間儲存undo資料，可以進行清理。
重要
- 升級資料庫版本可能存在相容性問題，請仔細閱讀升級資料庫版本中的功能限制和版本差異。
- 資料庫升級過程中，RDS會進行執行個體切換，請您盡量在業務低峰期執行升級操作，並確保您的應用有自動重連機制。執行個體切換的影響請參見執行個體切換的影響。

後續維護

減少並及時最佳化慢SQL。
盡量在業務低峰期進行索引建立刪除、表結構修改、表維護和表刪除操作。
監控和清理執行時間過長的會話或事務。詳情請參見查看監控資訊。

ApsaraDB RDS：MySQL系統檔案導致執行個體空間滿的解決方案