1. 原因

2. 解決

2.1 Binlog 文件

2.2 數據文件

2.3 臨時文件

2.4 係統文件

---

RDS for MySQL 實例日常使用中隨著實例的使用，會出現空間使用告警甚至超過實例限額被鎖定的情況。

比如：

 

1. 原因

• Binlog 日誌文件占用高

• 數據文件占用高

• 臨時文件占用高

• 係統文件占用高

實例空間使用情況可以在 RDS 控製台監控報警中查看：

2. 解決

RDS 實例支持單獨升級磁盤空間，升級磁盤空間是解決空間問題的有效方式之一。下麵說明不升級空間的情況下解決空間問題的方法。

2.1 Binlog日誌文件

Binlog 文件記錄實例的事務信息，是 RDS MySQL 實例 HA 架構以及高可用性、可恢複性的基礎。是不可以關閉的。

RDS 實例會以一定時間間隔自動清理（上傳到 RDS OSS 並從實例空間中刪除）最近 18 小時外的 Binlog 文件。

如果短時間內實例 DML 操作生成了大量 Binlog 數據，有可能會導致超過實例磁盤空間上限而被鎖定。

在這種情況下，可以通過控製台  備份與恢複  一鍵上傳 Binlog 來清理（將 Binlog 文件上傳到 RDS 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 提供的是根據采樣獲取的表的部分統計信息，因此通過下麵的查詢獲取的表、庫數據尺寸和實際數據文件占用尺寸間會有出入（通常要小於實際數據文件占用空間）

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

 

下圖中可以看到：在收集表的統計信息前後反饋出的表數據量大小存在差異。

• 注：
  即使通過 analyze table 命令，重新收集統計信息，得到的數值通常也小於實際數據文件占用空間；比如本例的 16143 MB 也小於該表的數據文件實際占用空間。

由於數據文件在頻繁的 DML 後會出現數據空洞的現象，比較接近實際數據文件占用空間的計算方法請參考：

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

 

• 注：
  因為 information_schema.tables 中提供的是采樣統計數據，因此該計算方式在統計數據比較接近實際的情況下，才會比較接近真實空間占用情況。

2.2.2 delete 刪除數據

delete 操作不能夠直接回收被刪除數據占用的數據文件空間，這就好比排空泳池中水但泳池的占地麵積不會發生改變一樣。而且 delete 操作會生成相應的 Binlog 文件，會進一步惡化空間使用情況。

在 delete 操作刪除數據後，需要通過 optimize table tab_name; 操作來回收空間。

2.2.3  刪除備份

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

2.3 臨時文件

臨時文件會隨查詢的結束或者會話的終止而自動釋放，因此如果是臨時文件導致實例空間滿而鎖定，可以通過終止會話來釋放空間。

2.4 係統文件

係統文件涉及到 ibdata1 係統表空間文件和 ib_logfile0、ib_logfile1 日誌文件。

ibdata1文件：

InnoDB 引擎表由於支持多版本並發控製（MVCC），因此會將查詢所需的Undo信息保存在係統文件 ibdata1 中。

如果存在對一個 InnoDB 表長時間不結束的查詢，而且在查詢過程中表有大量的數據變化，則會生成大量的 Undo 信息，導致 ibdata1文件尺寸增加。

由於 MySQL 內部機製的限製，ibdata1 文件目前是不支持收縮的。

因此出現這樣的情況，在不升級磁盤空間的前提下，比較好的解決方法是在同地域同可用區購買相同配置的 RDS 實例，通過 DTS 工具將數據遷移到新實例中。

建議：監控和清理執行時間過長的會話或事務。

ib_logfile 日誌文件：

ib_logfile0 和 ib_logfile1 日誌文件保存 InnoDB 引擎表的事務日誌信息，其文件大小尺寸固定，不可以改變。較大的尺寸在高並發事務的場景下有利於減少事務日誌文件切換的次數，提高實例性能。