Aurora MySQL实例本地存储使用洞察及空间耗尽问题排查求助

问题描述 #

我有一个包含writer和reader实例的Aurora MySQL全局集群，实例配置如下：

• 实例规格：db.r7g.xlarge
• 已启用general_log、slow_query_log，log_output设置为FILE

遇到的故障：CPU使用率突然飙升至100%，其他指标同步急剧上升，服务无法连接数据库。故障发生时，数据库日志中多次出现**"No space left on device"**错误，该问题已重复出现两次，目前仅能通过手动切换读写实例实现临时修复。

查看存储指标情况：

• AuroraVolumeBytesLeftTotal剩余约140TB（共享存储，支持自动扩容）
• FreeLocalStorage剩余约80GB（单实例本地存储）

矛盾点：错误提示空间不足，但指标显示本地存储仍有剩余；且Aurora自带日志轮转策略——审计日志、通用日志、慢查询日志会在24小时后或存储占用达15%时轮转；FILE输出模式下，每小时会检查并删除超过24小时的日志文件。

需求：

1. 如何获取Aurora实例本地存储的更多使用详情？
2. 若当前排查方向有误，请帮忙分析问题根因？

故障时的部分日志 #

2024-05-13T11:40:34.710624Z 0 [Note] [MY-000000] [Repl] [Dump thread metrics] Secondary_id: 1012653105, Secondary_uuid: 549b2e36-46a4-491d-b8e1-c95eef81e275, Binlog_file: mysql-bin-changelog.002012, Binlog_position: 88516906, Bytes_behind_primary: 1875, Bytes_behind_primary (1875) is smaller than aurora_binlog_io_cache_size (134217728) by 134215853 (rpl_binlog_sender.cc:1945)
<*> <*> [Note] [<*>] [Server] Aborted connection <*> to db: <*> user: <*> host: <*> (Got an error reading communication packets). (sql_connect.cc:<*>)
<*> <*> [Note] [<*>] [Repl] [Dump thread metrics] Secondary_id: <*>, Secondary_uuid: <*>, Binlog_file: <*>, Binlog_position: <*>, Bytes_behind_primary: <*>, Bytes_behind_primary (<*>) is smaller than aurora_binlog_io_cache_size (<*>) by <*> (rpl_binlog_sender.cc:<*>)
2024-05-13T12:51:59.641538Z 21044534 [ERROR] [MY-010907] [Server] Error writing file '/rdsdbdata/log/general/mysql-general.log' (errno: 28 - No space left on device)
Uh oh, gzputs operation on GzipFile /rdsdbdata/log/aurora-engine-logs/grover.mysqld.2024-05-12-22-03-58.260.10.log.gz failed: No space left on device
Uh oh, gzflush operation on GzipFile /rdsdbdata/log/aurora-engine-logs/grover.mysqld.2024-05-12-22-03-58.260.10.log.gz failed: No space left on device
2024-05-13T12:36:12.281249Z 21042731 [ERROR] [MY-010907] [Server] Error writing file '/rdsdbdata/log/general/mysql-general.log' (errno: 28 - No space left on device)

一、获取本地存储更多使用洞察的方法 #

1. 控制台查看多维度本地存储指标
   进入Aurora实例详情页的「监控」标签，在「全部指标」中筛选「本地存储」分类，除FreeLocalStorage外，重点关注LocalStorageUsed、LocalStorageTotal的实时变化趋势，确认故障发生时段的实际存储占用（指标存在周期性统计延迟，你看到的80GB可能是故障恢复后的数值）。

2. 用AWS CLI精准查询故障时段指标
   执行以下命令获取指定实例在故障窗口的本地存储使用数据：

   aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name LocalStorageUsed --dimensions Name=DBInstanceIdentifier,Value=你的实例ID --start-time 2024-05-13T12:00:00Z --end-time 2024-05-13T13:00:00Z --period 60 --statistics Average
   

   替换时间范围和实例ID，定位故障瞬间的存储占用峰值。

3. 分析完整日志文件
   在RDS控制台「日志和事件」中，下载完整的aurora-engine-logs和general_log，搜索disk、space、inode等关键词，排查是否存在日志轮转失败、文件句柄耗尽或临时文件未清理的记录。

二、可能的根因分析 #

1. 日志轮转/压缩机制失效

   • 日志生成速率远超清理速度：若业务短时间内请求量暴增，general_log生成的日志文件速度超过每小时清理阈值，会快速占满本地存储。
   • 日志压缩失败：错误日志中显示gzputs、gzflush操作失败，说明CPU资源耗尽（此时CPU已达100%）导致无法完成旧日志压缩，未压缩的日志文件持续堆积，进一步加剧磁盘空间占用和CPU负载。

2. 临时文件堆积
   Aurora本地存储会用于临时表、排序缓冲区、二进制日志缓存等。如果业务存在大量复杂查询（如大表排序、多表联查），或查询异常中断导致临时文件未自动清理，会快速占用本地空间。

3. 指标统计偏差
   FreeLocalStorage指标通常为5分钟周期性统计，故障发生时的瞬间磁盘耗尽可能落在统计间隔之外，导致你看到的是故障恢复后的剩余空间，而非故障瞬间的真实状态。

4. inode耗尽
   即使磁盘空间有剩余，若生成大量小文件（如碎日志文件）导致inode（文件索引节点）耗尽，也会触发"No space left on device"错误，这种情况无法通过FreeLocalStorage指标发现，需通过日志或AWS支持确认。

三、临时修复与长期优化建议 #

• 临时修复：

  1. 若业务允许，临时关闭general_log释放本地空间；
  2. 重启实例（会导致短暂中断），触发日志清理和临时文件回收。

• 长期优化：

  1. 调整日志策略：将log_output改为TABLE，把日志存储到共享存储（AuroraVolume）；或通过参数组缩短日志保留时间；
  2. 优化业务查询：减少复杂查询，避免生成大量临时文件；仅在排查问题时开启general_log；
  3. 设置告警：在CloudWatch中配置LocalStorageUsed超过80%的告警，提前干预；
  4. 联系AWS支持：若怀疑是Aurora内部机制问题（如日志轮转bug），提交工单请求协助排查本地存储的详细使用情况。

内容的提问来源于stack exchange，提问作者Zaki