PostgreSQL在重建过程中卡住

遇到了同样的问题……在 Ubuntu 20.04 上使用 DO Droplet。尝试先从 Discourse 内部升级 Docker,但一直出现错误代码 137。然后我尝试从命令行重建 Discourse,它卡在了 The database is ready to accept connections。Ctrl+C 没有反应,所以我关闭了 SSH 并打开了一个新的,然后重新启动了 Discourse,它仍然可以工作但没有更新。我重启了 Droplet 并再次尝试从 Discourse 升级 Docker,这次成功了!然后我再次尝试重建 Discourse,但它仍然卡在同一个地方。再次关闭 SSH 并打开并重新启动 Discourse,但现在我看到了 Oops 屏幕!所以现在我的 Discourse 网站无法访问,我以前唯一能从 Oops 屏幕恢复的方法就是重建应用程序,但我现在做不到!

所以我现在很迷茫,因为我的 Discourse 和 Droplet 经验非常有限,我不知道现在还能做什么。docker_manager 是我 app.yml 中唯一使用的插件,所以我只能假设错误是由于 Docker 是一个较新版本,与我的 Discourse 版本不兼容?我不知道。我最后一次更新 Discourse 是在一月份,所以它也不是那么过时……

所以我的网站将一直处于关闭状态,直到这个问题被解决……除非我启动一个新的 Droplet 并重新设置所有东西,然后恢复我之前备份的 Discourse?这是我目前唯一的选择吗?:tired_face:

错误 137 是内存不足。我会尝试增加更多交换空间。如果您只有 1GB 内存,我可能会将其调整为 2GB,并可能还有 3 或 4GB 的交换空间。

您可以尝试

./launcher start app

但我怀疑数据库已经迁移得太远,无法用于旧容器。

如果您遇到困难并需要付费支持,请访问 Contact Us - Literate Computing

编辑:但这是我会做的:

你好,这里也有同样的错误。目前可以通过在app.yml中强制版本参数为v3.3.0来解决。架构AMD64,Ubuntu 18.04。奇怪的是,小版本失败了,上周更新到v3.3.0没有问题 :neutral_face:

1 个赞

如果有人遇到此问题并且愿意让我访问您的服务器,请给我发私信,以便我可以在出现问题的服务器上调试该问题。我已经尝试了多种方法,但无法重现此问题,这使得推送修复程序更加困难。

5 个赞

我在我的个人资料中看不到私信你的方法……

您需要达到信任等级 1 才能发送消息

查看您个人资料中的统计数据,您已经非常接近了

2 个赞

对于那些因 Discourse 宕机而遇到此问题的人,我发现您可以通过重启虚拟机然后运行 ./launcher start app 来至少恢复论坛的旧版本。在尝试重建而未重启实例/虚拟机后,此命令将无法正常工作。

我应该能在周一在受影响的虚拟机上升级 Ubuntu 版本,届时会向大家通报结果。

1 个赞

当卡住时,Ctrl+c 不起作用,必须重新启动系统。

此命令也无效。

**/var/discourse**# ./launcher start app

检测到 x86_64 架构。

警告:containers/app.yml 文件是全局可读的。您可以通过运行以下命令来保护此文件:chmod o-rwx containers/app.yml

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=techoforum.com -e DISCOURSE_DEVELOPER_EMAILS=techoforumd@gmail.com -e DISCOURSE_SMTP_ADDRESS=smtp.sendgrid.net -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=apikey -e DISCOURSE_SMTP_PASSWORD=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 -e DISCOURSE_SMTP_DOMAIN=gmail.com -e DISCOURSE_NOTIFICATION_EMAIL=techoforumd@gmail.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h discourseonubuntu2004-s-1vcpu-1gb-sfo3-01-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f8:99:7d:c3:d6 local_discourse/app /sbin/boot

在本地找不到镜像 'local_discourse/app'

docker:守护进程的错误响应:拉取访问被拒绝,镜像 'local_discourse/app' 不存在或可能需要 'docker login':拒绝:请求访问该资源被拒绝。

请参阅 'docker run --help'。

我在另一个液滴上还有另一个论坛,更新时没有出现任何问题。奇怪的是,为什么在相同的服务器配置下,一个液滴有问题而另一个没有?

这听起来像是内存(RAM)问题。您有多少内存和交换空间?我建议添加一两个 GB 的交换空间(如果您只有 1GB 内存,也可以考虑添加内存)

这些系统有多少内存和交换空间?输出是什么?

free -h

内存问题可以解释为什么 @tgxworld 无法重现它。

我相当确定问题出在内存/交换空间上。

顺便说一句,对于遇到此问题的任何人,您可以通过将 base_image: discourse/base:2.0.20240708-0023 添加到 containers/app.yml 文件的顶部来暂时解决此问题。

5 个赞

不确定这是否是我的内存问题,因为受影响的虚拟机分配了 125 GiB 内存,可用内存为 78 GB。

              total        used        free      shared  buff/cache   available
Mem:           125G         14G        940M         31G        110G         78G
Swap:            0B          0B          0B

在没有此问题的情况下成功升级的具有相同操作系统的开发服务器只有 16 GiB RAM。

1 个赞

糟糕。这本可以解释一切。 :person_shrugging:

1 个赞

这可能是数据库大小的问题吗?

我们生产服务器上的数据库相当大,但开发环境的数据库却很小。这是已成功升级的虚拟机和受影响的虚拟机(就我而言)之间唯一的真正区别。

也许,您更改了数据库的内存配置?

数据库有多大?

1 个赞

我会去看看它是否已更改

这是唯一对我有效的方法。感谢分享!!我的客户也感谢您 :slight_smile:

希望我们能尽快得到妥善的修复。

1 个赞

您好,
我刚刚将 Droplet 的内存加倍并增加了磁盘大小。我仍然遇到同样的问题。
还有什么可以尝试的吗?

# free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       289Mi        83Mi        11Mi       1.6Gi       1.5Gi
Swap:         2.0Gi       3.0Mi       2.0Gi

# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            941M     0  941M   0% /dev
tmpfs           198M  1.1M  197M   1% /run
/dev/vda1        34G   14G   21G  39% /
tmpfs           986M     0  986M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           986M     0  986M   0% /sys/fs/cgroup
/dev/vda15      105M  7.4M   97M   8% /boot/efi
/dev/loop1       56M   56M     0 100% /snap/core18/2829
/dev/loop2       56M   56M     0 100% /snap/core18/2823
/dev/loop3       92M   92M     0 100% /snap/lxd/29619
/dev/loop0       64M   64M     0 100% /snap/core20/2264
/dev/loop4       64M   64M     0 100% /snap/core20/2318
/dev/loop5       39M   39M     0 100% /snap/snapd/21465
/dev/loop6       92M   92M     0 100% /snap/lxd/24061
/dev/loop7       39M   39M     0 100% /snap/snapd/21759
tmpfs           198M     0  198M   0% /run/user/0
overlay          34G   14G   21G  39% /var/lib/docker/overlay2/3c7ebf42647de2b5df34cba2b047079fd3454ea7fe9b04c7b70f227df1e7eafe/merged
1 个赞

我的天!我为什么之前没有看到这个解决方案。它也对我有用。
那么,未来的解决方案是什么?我们将来还需要继续指定这个基础镜像,还是更改它以获取更新的镜像?