Discourse 导致 postgres 12 升级失败

我们目前运行的是 PostgreSQL v12,因为升级到 v13 需要过多的磁盘空间。看起来与 v12 的兼容性可能已被破坏?这是故意的吗?如果是的话,意味着我们将永远无法再升级 Discourse。

运行 ./launcher start app 后服务已恢复在线,因此目前并非生产环境问题,但无法进行升级(即使是出于安全原因等)对我们来说将是极其糟糕的情况。

来自 app.yml 的内容:

  - "templates/postgres.12.template.yml"

运行 ./launcher rebuild app 的结果:

FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
失败位置:/pups/lib/pups/replace_command.rb:8:in `read'
替换失败,参数如下:{"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** 引导失败 ** 请向上滚动并查找更早的错误信息,可能不止一条。
./discourse-doctor 可能有助于诊断问题。

当前运行版本为 2.8.0.beta4 75b0d6df93。

它正在寻找 PostgreSQL 13 而不是 12。

{“filename” => “/etc/postgresql/13/main/pg_hba.conf”,

确实,这就是问题所在。

为什么不先进行备份,然后创建一个全新的 Discourse 实例(默认应使用 PostgreSQL 13),再恢复备份并更新 DNS 中的服务器映射呢?

2 个赞

没错,那样行得通。我正拼命避免不得不那么做。

1 个赞

这听起来可能有点吓人,但你那里有足够的保障措施,随时可以将旧服务器重新上线。

1 个赞

这比那些我想避免的烦人工作要让人安心一些,再加上还得告诉论坛用户他们会丢失一两天的帖子。理想情况下,Discourse 团队会说:“当然,我们仍在支持 PG12,这只是一个 bug,我们会尽快修复。”

我不明白这有什么必要。

  1. 在子域名上准备新服务器?

  2. 将现有服务器设为只读模式,并创建备份

  3. 将备份迁移到新服务器

  4. 重新映射 DNS

  5. 使用主 Discourse 子域名重建新服务器。

这个过程需要 30 分钟吗?

2 个赞

不,我运营的是一个非常大的论坛。

2 个赞

啊!这是个令人愉悦的问题!:slight_smile:

我想,我又没拿工资!:wink:

1 个赞

哦,我明白了,这是由社区提交的 PR 引入的一个 bug。由于我们任何地方都没有运行 PG12,所以这个问题一直没被发现。请给我几分钟时间。

5 个赞

已在以下地址修复:

@Wingtip,能否请您再次尝试重新构建?

不过,我们已不再运行 PG12,因此核心代码中随时可能引入仅适用于 PG13 及更高版本的 SQL 语法。因此,最好能安排时间进行升级。

5 个赞

我会在给我的虚拟机再拍一张快照后立刻查看。

PostgreSQL 升级需要占用大量磁盘空间,这真的让人很恼火。Oracle 和 MySQL 就没有这个问题,它们可以直接原地升级。

pg_upgrade 提供了一个 --link 标志,以支持原地升级。

在我们的“新手友好型”启动器升级脚本中,我们选择使用该标志,因为 99% 的安装环境运行在云虚拟机上,可以轻松且低成本地扩展磁盘空间。

不过,对于希望在升级过程中节省磁盘空间并选择手动升级的用户,该选项仍然可用。

1 个赞

当时提供了两种解决方案;据我回忆,一种方案需要整个数据库三倍的空间,另一种则需要大约两倍的空间。如果能在原地完成操作,将这一点记录下来会非常有用。

编辑:修复已生效,谢谢!

2 个赞

是的,我复制粘贴时没多想——抱歉,也感谢你的修复!

1 个赞

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.