环境：Ubuntu + Docker
主要数据库：PostgreSQL 15

1. 问题背景：历史日志表疯狂吃盘，nextjs巨大漏洞必须升级

在实际用 Dify 一段时间后，Postgres 的 workflow_node_executions 和 workflow_runs 这两张表很容易积攒出几十 G 的历史运行日志，而应用数据（messages、conversations 等）反而占空间很小。久而久之，整个库轻松上百 G，直接拖慢备份、升级与维护。

2. 常规手段不好使：VACUUM FULL / pg_repack 踩坑

许多朋友可能会第一时间想到用 VACUUM FULL 或 pg_repack 对大表做瘦身：

• VACUUM FULL 虽然能释放空间，但会长时间锁表，业务直接停摆；
• pg_repack 理论上可以在线重建表，实际操作还是需要大量额外空间，否则直接磁盘写爆，轻则卡死，重则数据损坏。

对几十 G 的大表，这两种手段都不现实。风险太大，得另寻他法。

3. 最优方案：pg_dump 排除日志表，轻装上阵

真正稳健的做法是：

• 用 pg_dump 只导出有用数据，日志类大表的数据直接排除；
• 恢复时表结构仍在，但内容干净如新，空间瞬间释放！

4. 注意事项

由于我dify没用到知识库所以知识库相关的问题我没注意，所以这种方法有可能会把知识库搞崩，总的来说一定要做好备份，到时候出问题了让大模型帮你迁移版本。

步骤简明总结

1. 导出数据（排除日志表数据）：

   pg_dump -U postgres -d dify \
     --exclude-table-data=public.workflow_runs \
     --exclude-table-data=public.workflow_node_executions \
     -F c \
     -f ./dify_without_workflow_logs.dump
   

   • 只排除数据，表结构仍在，方便后续业务正常写入。

2. 重建数据库目录：

   • 备份旧的数据目录（PGDATA），新建空目录启动 Postgres。

3. 导入精简后的 dump：

   pg_restore -U postgres -d dify --clean --if-exists ./dify_without_workflow_logs.dump
   

   • 这一步恢复后，日志表几乎空无一物，数据盘瞬间轻盈。

4. 升级过程中的前端“幽灵日志”问题与解决办法

升级后如果发现访问日志页面报 Cannot read properties of null (reading 'status') 这类前端 NPE，大概率是由于历史日志表数据没了，但引用关系还在。

解决方式

• SQL 一键清理所有“找不到对应 run”的日志行：

  DELETE FROM workflow_app_logs
  WHERE workflow_run_id NOT IN (SELECT id FROM workflow_runs);
  VACUUM ANALYZE workflow_app_logs;
  

  • 清掉这些孤儿记录，前端就能正常显示日志列表，不会报错啦！

5. 迁移和升级操作

• 清理后的数据库卷直接 cp -a 复制到新版本的 Docker 卷挂载目录下；
• （可选）应用存储卷（如用户上传文件等）也可同步迁移；
• docker-compose 挂载没问题后，启动新服务即可。

6. 总结：大库瘦身 & 升级的关键建议

1. 别硬刚 VACUUM FULL / pg_repack

   • 大表容易锁死或吃满磁盘，风险太高。

2. 巧用 --exclude-table-data

   • 只清表数据不动结构，升级更平滑。

3. 及时清理跨表“孤儿记录”

   • 只保留有用数据，避免前端异常。

4. 卷级迁移，简单安全

   • 数据清理后卷级别复制，比逻辑导入高效。

5. 备份不可少，谨慎删老数据

   • 保留一份旧库，验证无误再删除。