dki*_*hel 9 postgresql index disk-space vacuum postgresql-9.4
我在 Mac (10.10.4) 上运行 postgres (postgis) 9.4.2。
我有几张大桌子(几个 TB)。
在其中一个索引构建过程中大约需要一周时间,我看到可用的高清空间下降,正如您所期望的那样,当停电时间比电池单元和系统持续时间更长时索引将完成下楼。我fillfactor=100在构建期间关闭了缓冲区,因为它是一个静态数据源。重新启动时,驱动器上剩余的可用空间正是索引构建接近结束时的位置。真空分析不会释放空间。
我尝试放下桌子并重新摄取,但并没有减少空间。现在我所在的地方没有足够的空间来构建索引。
索引构建期间生成的文件是否由于停电期间机器停机的方式而无法被系统删除?
当我查看数据库中的表大小 + 索引(这是该驱动器上唯一的数据)时,它们加起来大约6TB。驱动器为8TB,驱动器上剩余的空间不足500GB,因此似乎在某处丢失了大约 1.5TB,这与索引的大小差不多。
有任何想法吗?
通常我们希望当 postgres 重新启动时,崩溃恢复过程会从数据目录中删除与回滚索引相关的文件。
让我们假设它不起作用,或者至少必须手动检查它。
可以使用如下查询建立应该在 datadir 中的文件列表:
select pg_relation_filenode(oid)
from pg_class
where relkind in ('i','r','t','S','m')
and reltablespace=0
order by 1;
Run Code Online (Sandbox Code Playgroud)
reltablespace=0用于默认表空间。如果有问题的索引是在非默认表空间中创建的,则0必须将其替换为pg_tablespace.
i,r,t,S,m inrelkind分别对应索引、表、toast 空间、序列、物化视图。所有这些对象在名称匹配的文件中都有它们的数据pg_relation_filenode(oid)。
在磁盘上,所述数据文件是以下$PGDATA/base/oid/其中oid是oid由数据库获得select oid,datname from pg_database。如果我们不是在谈论默认表空间,base则替换为PG_version_somelabel。
列出并排序该目录中与 relfilenodes 匹配的文件:
ls | grep -E '^[0-9]+$' | sort -n > /tmp/list-of-relations.txt
Run Code Online (Sandbox Code Playgroud)
(对于大于 1Gb 的关系,实际上只保留第一段。如果存在未附加到任何内容的挥之不去的段,则应单独考虑)
并将该文件与上述查询的结果进行比较。
如果存在与数据库知道的任何对象不对应的延迟数据文件,它们应该出现在该差异中。
| 归档时间: |
|
| 查看次数: |
665 次 |
| 最近记录: |