我们目前运行的是 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。
IAmGav
(Gavin Perch)
2
它正在寻找 PostgreSQL 13 而不是 12。
{“filename” => “/etc/postgresql/13/main/pg_hba.conf”,
为什么不先进行备份,然后创建一个全新的 Discourse 实例(默认应使用 PostgreSQL 13),再恢复备份并更新 DNS 中的服务器映射呢?
2 个赞
这听起来可能有点吓人,但你那里有足够的保障措施,随时可以将旧服务器重新上线。
1 个赞
这比那些我想避免的烦人工作要让人安心一些,再加上还得告诉论坛用户他们会丢失一两天的帖子。理想情况下,Discourse 团队会说:“当然,我们仍在支持 PG12,这只是一个 bug,我们会尽快修复。”
Falco
(Falco)
12
哦,我明白了,这是由社区提交的 PR 引入的一个 bug。由于我们任何地方都没有运行 PG12,所以这个问题一直没被发现。请给我几分钟时间。
5 个赞
Falco
(Falco)
13
已在以下地址修复:
@Wingtip,能否请您再次尝试重新构建?
不过,我们已不再运行 PG12,因此核心代码中随时可能引入仅适用于 PG13 及更高版本的 SQL 语法。因此,最好能安排时间进行升级。
5 个赞
我会在给我的虚拟机再拍一张快照后立刻查看。
PostgreSQL 升级需要占用大量磁盘空间,这真的让人很恼火。Oracle 和 MySQL 就没有这个问题,它们可以直接原地升级。
Falco
(Falco)
15
pg_upgrade 提供了一个 --link 标志,以支持原地升级。
在我们的“新手友好型”启动器升级脚本中,我们选择不使用该标志,因为 99% 的安装环境运行在云虚拟机上,可以轻松且低成本地扩展磁盘空间。
不过,对于希望在升级过程中节省磁盘空间并选择手动升级的用户,该选项仍然可用。
1 个赞
当时提供了两种解决方案;据我回忆,一种方案需要整个数据库三倍的空间,另一种则需要大约两倍的空间。如果能在原地完成操作,将这一点记录下来会非常有用。
编辑:修复已生效,谢谢!
2 个赞
fuerst
(Bernhard Fürst)
17
是的,我复制粘贴时没多想——抱歉,也感谢你的修复!
1 个赞
system
(system)
关闭
19
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.