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