时间戳

首页 > 解决方案 > Postgres DB 大小是预期的 3 倍

database - Postgres DB 大小是预期的 3 倍

问题描述

每天晚上，我们都会截断数据库中的大部分表并从远程数据库中插入数据。我们每晚插入的数据总大小约为 300 GB。

问题是数据库大小要大得多：

SELECT pg_size_pretty( pg_database_size('comb') );

 pg_size_pretty 
----------------
 943 GB
(1 row)

此外，data/base 目录中有很多旧文件（例如从 2020 年开始）没有出现在 pg_class 中：

cd data/base
ll 935829*

-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.1
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.2
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.3
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.4
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.5
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.6
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.7
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.8
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.9
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.10
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.11
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.12
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.13
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.14
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.15
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.16
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.17
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.18
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.19
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.20
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.21
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.22
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.23
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.24
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.25
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.26
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.27
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.28
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.29
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.30
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.31
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.32
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.33
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.34
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.35
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.36
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.37
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.38
-rw------- 1 postgres postgres 1073741824 Sep  4  2020 935829.39




  SELECT relname, relnamespace::regnamespace, relkind FROM pg_class WHERE relfilenode =  935829;
     relname | relnamespace | relkind 
    ---------+--------------+---------
    (0 rows)
    
    Time: 8.156 ms

我们尝试执行 VACUUM FULL 以将未使用的空间释放给操作系统。它成功完成，但没有为操作系统释放空间。

上次发生这种情况时，我们执行了逻辑备份 (pg_dump) 并还原以缩小该数据库。

这次我们想弄清楚这个问题的原因。

请指教。

标签： databasepostgresqlcorruptionvacuum

解决方案

首先，找出文件是否属于现有关系（假设关系在默认表空间中）：

SELECT pg_filenode_relation(0, 935829);

如果结果为 NULL，并且文件是旧的，您可以删除它们。

他们一定是在坠机后被抛在后面的。

推荐阅读