好主意，谢谢 Ed！我已经更新了帖子。
2 个赞
经过此更改，内存使用量总体减少了约 4%。干得漂亮。
2 个赞
谢谢Lilly，我刚才进行了升级，一切看起来都很顺利 
1 个赞
重写后的表和索引往往更加紧凑，这并不罕见。
1 个赞
嗯，那属于运行 Postgres 时的正常噪音（具体取决于你是在 vacuum、表重建等操作之前还是之后查看的）
从那以后，我没有发现任何缺失的内容，所以据我所知，一切正常。
1 个赞
我在 /var/discourse 目录下以独立 Docker 容器的形式运行 Discourse。
我尝试将内置的 PostgreSQL 数据库从版本 15 升级到 18。升级过程看似已完成，当前活动数据目录报告如下：
/shared/postgres_data/PG_VERSION
18
然而，重建后的 Discourse 容器中仍然只包含 PostgreSQL 15 的二进制文件：
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
PostgreSQL 服务被配置为运行：
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
而实际的 Discourse 数据目录挂载在：
/shared/postgres_data
因此，PostgreSQL 出现以下错误：
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
我理解近期的 Discourse Docker 镜像应该包含 PostgreSQL 18 的二进制文件。我将 app.yml 修改为使用 PostgreSQL 18 模板并重新构建了应用，但生成的容器中仍然只有 PostgreSQL 15 的二进制文件，且服务脚本仍然指向 /etc/postgresql/15/main。
我当前服务配置的相关部分如下：
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
我的问题是：
-
正确重建或更新 Discourse 容器以使其实际包含 PostgreSQL 18 二进制文件的方法是什么？
-
在
app.yml中是否应该使用特定的模板或镜像标签？ -
一旦 PostgreSQL 18 可用，针对现有的
/shared/postgres_data目录启动它的受支持流程是什么？
我没有删除或重新初始化 PostgreSQL 18 的数据目录。我希望能恢复已升级的集群，而不是还原旧的 PostgreSQL 15 数据。
1 个赞
根据 OP 中的说明，除非我漏掉了什么，否则这一步似乎是多余的？
仅仅重新构建标准安装应该就会拉取最新的镜像并触发迁移。
除非你以某种方式排除了最新镜像，否则新的二进制文件应该是确定会获取到的？ 真是奇怪……
你确定没有固定（pin）镜像版本吗？
3 个赞
我并没有故意固定版本？我使用的是常规的 git 仓库和分支，而且我的 app.yml 中没有任何迹象表明我固定了任何内容。我只是改用了 postgres 18 模板，想看看是否有帮助；是的，那确实是一个没有帮助的多余步骤，所以我可以改回去。
关于如何获取新的二进制文件，有什么建议吗？尽管我重建了很多次，它们真的不在那里：
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
1 个赞
为了节省您的时间和精力，我建议考虑使用您最新的备份来创建一个新的服务器，这样可以为您省去大量工作。
1 个赞
好吧，我想也是！有时候折腾半天去修东西确实不值得。谢谢。
2 个赞
如果你的 Discourse 出了故障，导致无法访问管理面板，那么如何通过 root@ 获取数据库并上传到新实例？（也许有另一篇指南）
或者，有没有什么命令行指令可以执行与管理面板中相同操作？
好的，更关键的是，我需要重新构建应用来解决一个刚刚出现的证书错误（之前没有任何更改导致了这个明显的故障）——端口 443 无法访问的错误又出现了（向导提示：“DNS 验证失败”）——不知道是 Cloudflare 还是 DigitalOcean 改了什么，但再次强调，我这边没有任何改动——不过这次我可能因为这两个错误（包括下面这个）而无法重新构建，上次是空间不足的错误，有人知道怎么解决下面这个错误吗？
补充一下，在扩大主磁盘容量（考虑到 Postgres 15 升级到 18 的需求）之前和之后，我也遇到过完全相同的错误。
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
啊，好的，我找到了我认为需要的内容，是 @Lilly 很久之前在这个主题里发的。
cd /var/discourse
./launcher enter web_only
discourse backup
exit
根据这些，我假设我可以生成一个可用的数据库备份，然后上传到一个全新的 Discourse 实例中，从而绕过所有问题。
这个命令会生成完整的备份吗，也就是说包含帖子 + 上传的图片/文件？
我建议仅备份数据库，并使用 rsync 迁移其他所有内容。使用 rsync 将 Discourse 站点迁移到另一台 VPS。你还可以通过 rsync 同步 SSL 证书，这样可以在更改 DNS 之前先启动新站点。
编辑：抱歉。我不确定你是否已经解决了问题。如果我没理解错的话，最简单的做法是切换回默认的无版本模板并重新构建。
2 个赞
你是否按照要求将数据（在你的情况下可能是 app）容器重建了两次？
（顺便说一下，更新信息中提到要重建 app，但我猜它指的是“可能被称为 app 或 data 的数据库容器”，还是说两者都需要重建？）
另外，我想给点反馈。之前我尝试从 13 升级到 15，但多次失败，最后只能停留在 .13 模板上。现在 .18 版本可用了，我又试了一次，这次没有任何问题（我只需在之前清理一下 _new 和 _older 目录）。所以现在我又可以运行默认的无版本数据模板了。所以，恭喜你们让更新过程变得如此稳健！
1 个赞