RDS MySQL 空間問題的原因和解決

標籤：小尺寸   http   解決   清理   間隔   alt   收集統計資訊   影響   16px   

來源：https://help.aliyun.com/knowledge_detail/41739.html

 

RDS MySQL 空間問題的原因和解決

更新時間：2016-07-22 17:20:14

1. 原因

2. 解決

2.1 Binlog 檔案

2.2 資料檔案

2.3 臨時檔案

2.4 系統檔案

RDS MySQL 執行個體日常使用中隨著執行個體的使用，會出現空間使用警示甚至超過執行個體限額被鎖定的情況。

比如：

1. 原因

• Binlog 檔案佔用高

• 資料檔案佔用高

• 臨時檔案佔用高

• 系統檔案佔用高

執行個體空間使用方式可以在 DMS 診斷報告中查看：

• ins_size - 執行個體整體空間

• other_size - 系統檔案和臨時檔案使用空間

• data_size - 資料檔案使用空間

• binlog_size - Binlog 檔案佔用空間

註：擷取執行個體診斷報告的步驟請參考 如何訪問RDS 執行個體診斷報告 。

2. 解決

RDS 執行個體支援單獨升級磁碟空間，升級磁碟空間是解決空間問題的有效方式之一。下面說明不升級空間的情況下解決空間問題的方法。

2.1 Binlog檔案

Binlog 檔案記錄執行個體的事務資訊，是 RDS MySQL 執行個體 HA 架構以及高可用性、可恢複性的基礎。是不可以關閉的。

RDS 執行個體會以一定時間間隔自動清理（上傳到 OSS 並從執行個體空間中刪除）最近 18 小時外的 Binlog 檔案。

如果短時間內執行個體 DML 操作產生了大量 Binlog 資料，有可能會導致超過執行個體磁碟空間上限而被鎖定。

在這種情況下，可以通過控制台  備份與恢複  一鍵上傳 Binlog 來清理（將 Binlog 檔案上傳到 OSS 並從執行個體空間中刪除）。

一 鍵上傳 Binlog 會在後台非同步提交清理任務，因此點擊後會很快返回。清理任務會將完成寫入的 Binlog（當前正在被寫入的 Binlog 檔案由於未完成寫入，是不可以被清理的）上傳到 RDS 的 OSS （非使用者購買OSS）上後才會從執行個體空間中刪除 Binlog 檔案，因此會有一定延遲，建議點擊後耐心等待一定時間，不建議非常多次點擊該按鈕。

註：對於執行個體由於 DML 等操作（比如涉及大欄位的 DML 操作）導致快速產生 Binlog 的情況，可能會出現多次點擊”一鍵上傳 Binlog “ 按鈕但是 Binlog 空間依舊上漲的情況，這是因為上傳 Binlog 檔案到備份空間並且從執行個體空間中刪除的處理速度跟不上執行個體產生 Binlog 檔案的速度，在這種情況下，建議考慮升級磁碟空間，並且排查 Binlog 快速產生的原因。

2.2 資料檔案

對於資料檔案佔用空間高的情況，可以通過清理資料的方式來減少空間佔用情況，比如通過 drop table 和 truncate table 來清理不再需要的資料。

說明 3 個常見問題：

2.2.1 information_schema.tables 查詢的資料容量

information_schema.tables 提供的是根據採樣擷取的表的部分統計資訊，因此通過下面的查詢擷取的表、庫資料尺寸和實際資料檔案佔用尺寸間會有出入（通常要小於實際資料檔案佔用空間）

1. select table_name, concat(round((data_length + index_length) / 1024 / 1024,2),’MB’)from information_schema.tableswhere table_schema = ‘rd_test’and table_name = ‘large_tab_01’;

中可以看到：在收集表的統計資訊前後反饋出的表資料量大小存在差異。

註：即使通過 analyze table 命令，重新收集統計資訊，得到的數值通常也小於實際資料檔案佔用空間；比如本例的 16143 MB 也小於該表的資料檔案實際佔用空間。

由於資料檔案在頻繁的 DML 後會出現資料空洞的現象，比較接近實際資料檔案佔用空間的計算方法請參考：

1. select sum(data_length + index_length + data_free) / 1024 / 1024 from information_schema.tables;

註：因為 information_schema.tables 中提供的是採樣統計資料，因此該計算方式在統計資料比較接近實際的情況下，才會比較接近真實空間佔用情況。

2.2.2 delete 刪除資料

delete 操作不能夠直接回收被刪除資料佔用的資料檔案空間，這就好比排空泳池中水但泳池的佔地面積不會發生改變一樣。

在 delete 操作刪除資料後，需要通過 optimize table tab_name; 操作來回收空間。具體請參考：RDS for mysql 刪除資料後顯示空間沒有減少

2.2.3  刪除備份

RDS 備份放置在後台 OSS 上，不佔用使用者的 RDS 執行個體空間，因此刪除備份不能解決執行個體的空間問題。而且刪除備份會影響執行個體的可恢複性，強烈建議任何情況下不要考慮刪除備份。

2.3 臨時檔案

臨時檔案會隨查詢的結束或者會話的終止而自動釋放，因此如果是臨時檔案導致執行個體空間滿而鎖定，可以通過終止會話來釋放空間。

終止會話請參考：RDS MySQL 如何終止會話

臨時檔案常見問題請參考： RDS MySQL the table ‘/home/mysql/xxxx/xxxx/#tab_name’ is full 的原因和處理

2.4 系統檔案

系統檔案涉及到 ibdata1 系統資料表空間檔案和 ib_logfile0、ib_logfile1 記錄檔。

ibdata1檔案：

InnoDB 引擎表由於支援多版本並發控制（MVCC），因此會將查詢所需的Undo資訊儲存在系統檔案 ibdata1 中。

如果存在對一個 InnoDB 表長時間不結束的查詢，而且在查詢過程中表有大量的資料變化，則會產生大量的 Undo 資訊，導致 ibdata1檔案尺寸增加。

由於 MySQL 內部機制的限制，ibdata1 檔案目前是不支援收縮的。

因此出現這樣的情況，在不升級磁碟空間的前提下，比較好的解決方案是在同地區同可用性區域購買相同配置的 RDS 執行個體，通過 DTS 工具將資料移轉到新執行個體中。

建議：監控和清理執行時間過長的會話或事務，請參考：RDS MySQL 管理長時間執行查詢

ib_logfile 記錄檔：

ib_logfile0 和 ib_logfile1 記錄檔儲存 InnoDB 引擎表的交易記錄資訊，其檔案大小尺寸固定，不可以改變。較大的尺寸在高並發事務的情境下有利於減少交易記錄檔切換的次數，提高執行個體效能。

RDS MySQL 空間問題的原因和解決