PostgreSQL 18 升级前的数据库清理：日志/统计表的推荐保留期？

[scavin]

大家好，

我看到了针对自托管 Discourse 的 PostgreSQL 18 升级指南：

面向自托管用户的 PostgreSQL 18 更新

警告！ 如果您的数据库非常大，您将需要大量额外的磁盘空间（3倍于数据库大小），并且在执行此升级时必须格外小心！ 我们刚刚提交了更改，将我们的 Docker 镜像升级至 PostgreSQL 18。任何通过命令行重新构建 Discourse 的网站管理员都将从之前的 PostgreSQL 15 升级至 PostgreSQL 18。请注意，如果您在 2025 年 PostgreSQL 15 更新 发布时 选择暂缓升级，您可以跳过该步骤，直接升级至 PostgreSQL 18。 如果您之前暂缓了升级，请将 app.yml 中的 PostgreSQL 模板从 templates/postgres.13.template.yml 更改为 templates/postgres.template.yml。 与任何升级一样，强烈建议 在进行任何操作之前先进行备份。 区域设置变更 过去，我们曾发现当 glibc 更新（例如在操作系统升级期间）时会发生索引损坏。从 PostgreSQL 17 开始，出现了一种新的 内置区域设置提供程序，它与操作系统的 glibc 解耦，…

指南中提到，升级过程需要大量的额外磁盘空间，因此我在尝试迁移之前开始检查我的磁盘使用情况和数据库大小。

我当前的磁盘使用情况：

/dev/sda1        97G   44G   54G  45% /

我的 Discourse 数据库大小约为 21 GB。我发现大部分空间并非由帖子占用，而是由几个统计和日志表占用。

最大的表包括：

topic_views              5.2 GB
post_timings             1.9 GB
browser_pageview_events  1.8 GB
ai_api_audit_logs        1.6 GB
incoming_links           1.5 GB
user_auth_token_logs     1.2 GB

作为对比：

posts                    844 MB

我检查了数据范围：

topic_views:
2015-04-03 ~ 2026-08-03

incoming_links:
2015-04-09 ~ 2026-08-03

user_auth_token_logs:
2021-08-15 ~ 2026-08-03

ai_api_audit_logs:
2026-02-04 ~ 2026-08-03

browser_pageview_events:
2026-05-28 ~ 2026-08-03

我了解这些表有不同的用途，但我不确定对于生产环境的 Discourse 实例来说，合理的保留期是多少。

我的问题：

1. 对于 user_auth_token_logs，您通常保留记录多久？

   • 6 个月？
   • 1 年？
   • 为了安全审计保留更久？

2. 对于 incoming_links、topic_views 和 post_timings 这样的表，您通常保留所有历史数据，还是定期删除较旧的记录？

3. 在进行 PostgreSQL 主要版本升级之前，是否有任何推荐的清理或维护流程？

到目前为止，我还没有删除任何内容。我只运行了：

vacuumdb --analyze discourse

我的目标是在升级到 PostgreSQL 18 之前释放不必要的磁盘空间，同时保持 Discourse 的正常功能和有用的审计信息。

我很感激任何来自运行自托管 Discourse 站点的用户的建议或实际经验。

谢谢！