Amazon RDS Postgres可用存储从700GB骤降趋近于零，求排查方案

1. 基于RDS日志与监控的回溯分析 #

• 检查PostgreSQL日志：
  • 拉取事件时段的postgresql.log，搜索CREATE TABLE、COPY、INSERT、ALTER TABLE、VACUUM FULL、pg_dump/pg_restore等关键词，定位是否有批量数据写入、全量清理或备份恢复操作
  • 查看error.log中的异常信息，排查是否存在临时表未自动清理、大事务未提交导致的空间占用
• 分析CloudWatch历史指标：
  • 回溯WriteIOPS、WriteThroughput的突增时段，与FreeStorageSpace下降时间点做关联，判断写入负载类型
  • 查看DatabaseConnections指标，确认事件时段是否有异常连接数增长，对应潜在的批量操作发起源

2. 数据库对象空间占用排查 #

• 统计当前数据库对象的空间分布：
  • 执行以下SQL查询，找出占用空间最大的表/索引：

    SELECT
      schemaname,
      tablename,
      pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS total_size,
      pg_size_pretty(pg_relation_size(schemaname || '.' || tablename)) AS table_size,
      pg_size_pretty(pg_indexes_size(schemaname || '.' || tablename)) AS index_size
    FROM pg_tables
    ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC;
    

    对比日常基线，确认是否有表在事件后出现异常增长
  • 若使用分区表，检查各分区的大小，排查是否有新分区被批量写入
• 检查临时空间与遗留对象：
  • 执行SELECT * FROM pg_stat_user_tables WHERE schemaname = 'pg_temp';，排查是否有未清理的临时表
  • 查询pg_stat_activity的历史快照（若有留存），查看事件时段是否有长时间运行的临时表创建操作
• 排查WAL日志堆积：
  • 执行SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), pg_last_wal_replay_lsn()) AS wal_backup_lag;，检查WAL备份是否延迟，若归档失败会导致WAL文件占用大量实例存储

3. RDS服务侧操作核查 #

• 检查快照与备份操作：
  • 确认事件时段是否有手动快照、自动快照生成，或快照跨区域复制操作（虽快照不占实例存储，但部分备份相关的临时操作可能短时间占用空间）
• 查看维护任务记录：
  • 检查RDS控制台的事件历史，确认事件时段是否有引擎补丁升级、实例配置变更等维护操作，部分维护会生成临时文件占用空间
• 核查存储自动扩容记录：
  • 查看CloudWatch的AllocatedStorage指标变化，若空间骤降后触发了自动扩容，可反向推导原始空间被占满的时间点，缩小排查范围

4. 应用层操作回溯 #

• 核对业务操作日志：
  • 查看应用服务器在事件时段的日志，排查是否有批量数据导入、数据迁移、批量报表生成等操作
• 检查定时任务执行情况：
  • 确认是否有周/月级定时任务（如ETL、数据归档）在事件时段运行，排查是否因任务逻辑错误导致大量数据写入

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