升级失败，表现得非常精彩

支持
32

测试后的 Beta 版本最终会作为稳定版发布。根据对核心的更改大小，可能需要通过命令行执行特殊步骤。

VPS（虚拟专用服务器）是您为运行 Discourse 安装所付费的。除非您在家庭 PC 上运行；这通常是不受支持的安装。

我曾使用 Upcloud 作为我的 VPS 提供商。我现在使用 Cobtabo。

34

所有经过充分测试的 Beta 版本最终都会成为人们所说的稳定版本。

在 Moin 提供的链接中，您会看到：

  • Beta 仍在测试中（不建议用于生产环境）
  • Tests Passed（通过了大量测试，并被认为已准备好投入生产）团队推荐的安全分支。
  • Stable（如果您运行自己的自定义插件和主题/主题组件）。优点是更改非常缓慢。但您面临的安全风险更大，因为更新缓慢。

托管的 Discourse 计划通常使用 Tests-Passed 分支，以确保最佳的安全性和良好的稳定性。

请不要误会我的意思。但您不熟悉 VPS 等术语，这表明您对此非常陌生。您是自己安装的 Discourse，还是继承了一个 Discourse 论坛？我们都曾是 Discourse 设置/维护的新手。

36

这不是意见。如果您选择使用的软件，那它就是一个事实。这与您使用的绝大多数开源甚至闭源软件相当。我写了 vps。Android 将 V 和 P 大写了。

不过，我猜如果您真的不想学习，您就只能自己摸索了。

祝您好运！ :clinking_beer_mugs::smiling_face_with_sunglasses::+1::sparkles:

37

我注意到 @anon55243134 删除了几乎所有的帖子。我真的认为团队和维护更新脚本以及围绕更新的消息传递方面都有需要吸取的教训。

@anon55243134 多年来一直在运行自托管的 discourse，现在却遇到了一个损坏且无法正常工作的安装——仅仅是因为遵循了升级提示。

如果这发生在我身上，我会非常生气和痛苦，因为我可能会丢失论坛内容。选择了自托管，我可能没有能力或无法支付高昂的费用来修复它，即使有可能。

我认为警告和检查不足

  • 用户是否已进行最近的备份（不是托管服务快照！）
  • 用户是否已下载
  • 用户是否被告知基于 Web 的更新可能会失败并需要命令行更新
  • 用户是否被要求检查其操作系统是否非常旧
  • 用户是否被告知迁移到新的最新服务器可能是最佳方法
  • 用户是否被警告重大更新（例如数据库更新）可能很危险，如果经验不足，等待一周可能是个好主意，以便发现和修复问题

更令人担忧的是，在我看到的一些已删除的帖子中，有一些相当严重的故障没有被捕获，脚本却继续运行：

cat: /shared/postgres_data/PG_VERSION: No such file or directory
...
E: Unable to locate package postgresql--pgvector
cp: cannot stat '/etc/postgresql//main/*': No such file or directory
sh: 1: /usr/lib/postgresql/bin/postgres: not found
...
Finding the real data directory for the source cluster      
could not get data directory using "/usr/lib/postgresql/bin/postgres" -D "/shared/postgres_data" -C data_directory: No such file or directory
Failure, exiting

我没有检查脚本，但我认为不存在的东西预示着麻烦即将来临，是时候停止了。

5 个赞
38

抱歉又引发了一个旧问题！在我的案例中，我升级了Ubuntu和Postgres，然后在/var/discourse目录下重新运行了sudo ./launcher rebuild app，所有内容似乎都已正确重建，网站也恢复了。

感谢所有帮助我的人。我非常感激这份帮助，没有这个社区，我不知道我会处于何种境地。

谢谢！

5 个赞
39

这里肯定有改善Discourse的机会。自从拥有一个稳定的实例已经7到8年了，总有需要通过服务器命令行升级的时刻。文档中也有建议的频率。

然而，访问文档并不像它可以那么容易。文档类别插件无疑是一个改进，但我仍然认为它还可以更好。

我的建议是增加在管理网页界面中的直接链接。也许可以在旁边加个（?）链接，弹出一些信息，以及指向Meta中的一个话题，提供更详细的信息。

用更新面板时，还可以用类似的方式显示额外信息，比如结合核心和Docker，可以让按钮变灰，并显示一条必需从服务器命令行执行的消息，链接到对应的版本说明，第一节详细说明需求。例如Docker版本X和Ubuntu LTS版本X（或其他官方支持的Linux发行版）。我认为链接的主题还应该包含一些可以直接复制粘贴到命令行的内容。

关于脚本，不确定怎么实现会更容易，但可以让初始脚本检查一些基本需求。如果缺少必要的依赖，则退出并显示消息，可能还会有一个链接，指导如何获取所需的基础信息。

升级失败的提示需要更直观。虽然提示向上滚动查看早期错误，但我发现有一些错误很常见且不影响重建。因此，导出导致重建失败的关键错误到日志文件会更好。不过这些建议的改变可能需要相当多的工作和时间。

关于#documentation:self-hosting，真正需要一个更全面的入门指南，介绍在自我托管之前应了解的内容，比如熟悉Ubuntu LTS的操作系统，基本的维护和发行版升级，备份的最佳实践，以及具体操作步骤。这些也许可以作为一个新话题，带标签，加入Staff类别，并链接到Meta。

如果我没记错，Bloomberg在这个话题中也做了一个很好的总结。作为我的一份歉意，我也要向@anon55243134道歉。不过他们也需要承担自己的责任。如果你来寻求帮助，就需要愿意倾听所说的内容，提供所要求的信息，这样大家才能引导他们找到可能的解决方案。

我们或许都有关于设计等方面的想法。但在没有实现改动之前，我们只能接受当前的状况。我知道遇到有害的停机时间是多么令人痛心。 前一段时间，我在我志愿担任管理员的客户那里遇到了问题。 当我因为服务器太小而无法重建应用程序，且这里的空间清理方法不能解决时，我向他们请愿了一个多月，他们忽视了我的建议，最终如我所警告的，服务器遭遇了严重崩溃。 他们最终雇了这里的一名成员来修复问题，结果涉及部署了一个空间充足的新服务器。 由于他们的疏忽，网站停机超过2个星期。 后来他们没有维护邮件服务器，虽然网站没有宕机，但邮件通知的缺失造成了很大损失。 我还能说很多，但这不是Discourse的问题，而是自托管的问题。

我早些时候遇到过一个重建问题，是由模板文件引起的。 日志中提供了足够的线索，可以猜测通过注释掉模板文件来解决问题。当这个问题出现在这里时，我发布了我所做的事，这也帮助团队识别了问题。

在各方面，我们都需要努力改进。 花时间阅读和倾听那些有经验和技能帮助解决问题的人。这就是我积累对能做事情的理解的方式。 对于那些我没有经验的事情（特别是Discourse的复杂性），我会尽力研究并寻求帮助，也会听取这里更擅长理解这款出色软件的人的建议。

@anon55243134，如果你愿意尝试，也许我们都可以帮你重新上线。 在此过程中，我们只需避免偏离“我们认为应该是的样子”，而接受“它现在的样子”。 一旦修复好，我们可以总结经验教训，开始关于如何改进的讨论，接受团队的反馈（通常他们都愿意），这可能需要一些时间，因为他们也要处理其他项目。 在我们这边，我们可以提出一些想法，那些真正有知识的人如果有时间，可以着手一些操作指南、最佳实践的资料等。

团结一心，人人皆能成功。 认为我们几乎一事无成的观点是不对的。

5 个赞