PostgreSQL 处理磁盘填满的策略

Question

我正在使用 PostgreSQL (8.4) 来存储由频繁插入的应用程序生成的数据（在下面描述的表结构中）。

数据库随着时间不断增长，并且由于新数据比旧数据更相关（在这个特定的应用程序中），删除旧行是一个合理的解决方案（基于 lowerid或 old input_datetime，或多或少相同） .

为了防止与此数据库（此服务器上运行的唯一数据库）相关的问题影响系统的其余部分，我将 PostgreSQL 数据目录放在其自己的分区（在 Linux 系统上为 ext3）。然而，当这个分区变满时，这会导致许多问题。

我正在考虑定期删除旧数据（例如DELETE FROM data_group WHERE id <= ...通过 cron 作业）来解决这个问题。

首先，我的理解VACUUM（由 auto-vacuum 执行，已开启）是，虽然它不一定将磁盘空间返还给操作系统（就像VACUUM FULL那样），但它仍然允许将一些新数据插入到已使用的磁盘空间（即DELETEs 不一定影响文件大小，但它们仍然在 PostgreSQL 自己的数据结构中释放空间）。这样对吗？（我注意到VACUUM FULL应用程序本身引起了一些问题，可能是因为它使用了锁。）

如果是这样，它似乎也SELECT pg_database_size('my_database')反映了磁盘上使用的大小，这不一定反映可用于进一步插入的内容。是否有另一种方法可以估算新插入物的可用空间？

此外，当为时已晚并且分区已填充到 100% 时，运行此DELETE语句会导致此错误并导致 PostgreSQL 服务崩溃：

恐慌：无法写入文件“pg_xlog/xlogtemp.7810”：设备上没有剩余空间

PostgreSQL 守护进程停止当然是一个主要问题（并且在这台机器上没有其他磁盘可以将集群移动到）。

是否有防止此类问题发生的通用策略（知道磁盘空间受限于给定分区内，但删除旧数据是可以接受的）？我想在没有rootor postgres（或 PostgreSQL 管理员）干预的情况下尽可能多地自动化。

---

CREATE TABLE data_group (
    id SERIAL PRIMARY KEY,
    name TEXT,
    input_datetime TIMESTAMPTZ
);

CREATE TABLE data_item (
    id SERIAL PRIMARY KEY,
    group_id INTEGER NOT NULL REFERENCES data_group(id) ON DELETE CASCADE ON UPDATE CASCADE,
    position INTEGER NOT NULL,
    data BYTEA
);

Answer 1

一方面，您可以查看我之前的一个答案，了解如何保持桌子大小或多或少稳定。在那里你会找到一个带有触发器的解决方案 - 当然，这也可以使用 cron 作业来解决。在后一种情况下，我将首先检查行数是否超过特定限制，然后删除最旧的行或删除分区。

另一方面，正如您已经注意到的，必须注意磁盘空间所在的位置pg_xlog。当它满了时，恢复起来就不那么容易了......但是检查你的数据库设置，你可以公平地估计你需要多少空间：

总是至少有一个 WAL 段文件，并且通常不会多于(2 + checkpoint_completion_target) * checkpoint_segments + 1或 个checkpoint_segments + wal_keep_segments + 1 文件。每个段文件通常为 16 MB（尽管在构建服务器时可以更改此大小）。您可以使用它来估计 WAL 的空间需求。通常，当不再需要旧的日志段文件时，它们将被回收（重命名为编号序列中的下一个段）。如果由于日志输出率的短期峰值而导致多于3 * checkpoint_segments + 1段文件，则不需要的段文件将被删除而不是回收，直到系统回到此限制以下。

如果您没有设置复制，则最大值为3 * checkpoint_segments + 1（乘以 16 MB）。我认为，典型的无复制设置需要 10 GB 以下的空间pg_xlog。