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 提供的是根據采樣獲取的表的部分統計信息，因此通過下面的查詢獲取的表、庫數據尺寸和實際數據文件占用尺寸間會有出入(通常要小于實際數據文件占用空間)

selecttable_name,concat(round((data_length +index_length)/1024/1024,2),’MB’)frominformation_schema.tableswhere table_schema =‘rd_test’andtable_name =‘large_tab_01’;

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

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

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

selectsum(data_length +index_length +data_free)/1024/1024frominformation_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 空間問題的原因和解決

標簽：小尺寸???http???解決???清理???間隔???alt???收集統計信息???影響???16px

本條技術文章來源于互聯網，如果無意侵犯您的權益請點擊此處反饋版權投訴 本文系統來源：http://www.cnblogs.com/doseoer/p/6130533.html

總結

以上是生活随笔為你收集整理的rds mysql 磁盘空间,RDS MySQL 空间问题的原因和解决的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。