☰

减少主/基地神秘堆积物的规模

tag-icon • tag-icon postgresql postgresql-9.3
减少主/基地神秘堆积物的规模

使用 PostgreSQL 9.3。我有一个长时间运行的查询，更新了大约 800 万行。显然出了问题。2 天后，我收到磁盘空间不足警报。我停止了查询，这就是我看到的结果。

root@server:/var/lib/postgresql/9.3/main# du -BM * | sort -n
1M  global
1M  pg_notify
1M  pg_serial
1M  pg_snapshots
1M  pg_stat
1M  pg_stat_tmp
1M  pg_tblspc
1M  pg_twophase
1M  PG_VERSION
1M  pg_xlog/archive_status
1M  mydb.opts
1M  mydb.pid
3M  pg_subtrans
7M  base/1
7M  base/12030
7M  base/12035
11M base/22029472
21M pg_clog
72M pg_multixact/offsets
315M    pg_log
444M    pg_multixact/members
516M    pg_multixact
625M    pg_xlog
3493M   base/pgsql_tmp
61851M  base/22053373
65372M  base

请注意：61851M base/22053373

由于我的实际数据位于存储在不同卷的表空间中，因此我推测这是一些堆积起来的临时交易内容。

网上有一些关于类似问题的帖子，但我没有找到规范的解决方案。一般来说，建议是“运行 VACUUM FULL”，有时累积的垃圾会消失。这就是我现在正在做的事情，但它需要时间，我担心我可能会填满剩余的磁盘空间（3GB）并导致一切崩溃。

有人有过这样的经历吗？这里存储了什么？有没有一种安全的方法可以快速释放这个空间？或者至少把它移到其他地方（我的表空间磁盘上有足够的空间）。

答案1

我搞明白了。这是我的失误。这是同事在默认表空间中创建的新数据库，而不是我们自定义的表空间之一。

对于那些遇到类似问题的人，以下是我在调查过程中学到的一些东西。base/22053373在我的例子中是数据库的 oid。您可以像这样查看它是哪个数据库：

SELECT oid, * FROM pg_database

里面的每个文件都以 pg 类型（表或其他）的 oid 命名。最大的文件可能来自您最大的表。连接到数据库并从pg_class集合中选择以找出哪个。

现在我正在使用将数据库移动到自定义表空间

ALTER DATABASE mydb SET TABLESPACE mytablespace;

我非常确定这能解决我的问题。

相关内容