other_size- 系統(tǒng)文件和臨時文件使用空間

data_size- 數(shù)據(jù)文件使用空間

binlog_size- Binlog 文件占用空間

注：獲取實例診斷報告的步驟請參考如何訪問RDS 實例診斷報告。

2. 解決

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

2.1 Binlog文件

Binlog 文件記錄實例的事務(wù)信息，是 RDS MySQL 實例 HA 架構(gòu)以及高可用性、可恢復(fù)性的基礎(chǔ)。是不可以關(guān)閉的。

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

如果短時間內(nèi)實例 DML 操作生成了大量 Binlog 數(shù)據(jù)，有可能會導(dǎo)致超過實例磁盤空間上限而被鎖定。

在這種情況下，可以通過控制臺?備份與恢復(fù)?一鍵上傳 Binlog 來清理(將 Binlog 文件上傳到 OSS 并從實例空間中刪除)。

一 鍵上傳 Binlog 會在后臺異步提交清理任務(wù)，因此點擊后會很快返回。清理任務(wù)會將完成寫入的 Binlog(當前正在被寫入的 Binlog 文件由于未完成寫入，是不可以被清理的)上傳到 RDS 的 OSS (非用戶購買OSS)上后才會從實例空間中刪除 Binlog 文件，因此會有一定延遲，建議點擊后耐心等待一定時間，不建議非常多次點擊該按鈕。

注：對于實例由于 DML 等操作(比如涉及大字段的 DML 操作)導(dǎo)致快速生成 Binlog 的情況，可能會出現(xiàn)多次點擊”一鍵上傳 Binlog “ 按鈕但是 Binlog 空間依舊上漲的情況，這是因為上傳 Binlog 文件到備份空間并且從實例空間中刪除的處理速度跟不上實例生成 Binlog 文件的速度，在這種情況下，建議考慮升級磁盤空間，并且排查 Binlog 快速生成的原因。

2.2 數(shù)據(jù)文件

對于數(shù)據(jù)文件占用空間高的情況，可以通過清理數(shù)據(jù)的方式來減少空間占用情況，比如通過drop table和truncate table來清理不再需要的數(shù)據(jù)。

說明 3 個常見問題：

2.2.1 information_schema.tables 查詢的數(shù)據(jù)容量

information_schema.tables 提供的是根據(jù)采樣獲取的表的部分統(tǒng)計信息，因此通過下面的查詢獲取的表、庫數(shù)據(jù)尺寸和實際數(shù)據(jù)文件占用尺寸間會有出入(通常要小于實際數(shù)據(jù)文件占用空間)

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

下圖中可以看到：在收集表的統(tǒng)計信息前后反饋出的表數(shù)據(jù)量大小存在差異。

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

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

selectsum(data_length +index_length +data_free)/1024/1024frominformation_schema.tables;

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

2.2.2 delete 刪除數(shù)據(jù)

delete 操作不能夠直接回收被刪除數(shù)據(jù)占用的數(shù)據(jù)文件空間，這就好比排空泳池中水但泳池的占地面積不會發(fā)生改變一樣。

在 delete 操作刪除數(shù)據(jù)后，需要通過 optimize table tab_name; 操作來回收空間。具體請參考：RDS for mysql 刪除數(shù)據(jù)后顯示空間沒有減少

2.2.3? 刪除備份

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

2.3 臨時文件

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

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

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

2.4 系統(tǒng)文件

系統(tǒng)文件涉及到 ibdata1 系統(tǒng)表空間文件和 ib_logfile0、ib_logfile1 日志文件。

ibdata1文件：

InnoDB 引擎表由于支持多版本并發(fā)控制(MVCC)，因此會將查詢所需的Undo信息保存在系統(tǒng)文件 ibdata1 中。

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

由于 MySQL 內(nèi)部機制的限制，ibdata1 文件目前是不支持收縮的。

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

建議：監(jiān)控和清理執(zhí)行時間過長的會話或事務(wù)，請參考：RDS MySQL 管理長時間運行查詢

ib_logfile 日志文件：

ib_logfile0 和 ib_logfile1 日志文件保存 InnoDB 引擎表的事務(wù)日志信息，其文件大小尺寸固定，不可以改變。較大的尺寸在高并發(fā)事務(wù)的場景下有利于減少事務(wù)日志文件切換的次數(shù)，提高實例性能。

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

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

本條技術(shù)文章來源于互聯(lián)網(wǎng)，如果無意侵犯您的權(quán)益請點擊此處反饋版權(quán)投訴 本文系統(tǒng)來源：http://www.cnblogs.com/doseoer/p/6130533.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。