我觉得他们确实有 
等待此 PR 合并后，请按照以下步骤操作：
大约 100GB 
好的
因此，在思考如何自动化此升级过程时，我意识到确定何时执行“跳过部署后迁移”这一操作相当复杂。
对于单容器安装，除非存在某种奇特的迁移（在我四年的经验中，这是我首次听说），否则采用这种方式并无优势。大多数升级涉及的迁移很少，甚至可能没有计算密集型迁移。
对于双容器安装，始终建议设置 SKIP_POST_DEPLOYMENT_MIGRATIONS。这样，如果迁移导致运行中的容器出现问题，您可以禁用站点，从而减少“在旧容器继续运行的同时引导新容器”这一功能带来的部分风险。但即便如此，并非每次升级都包含会导致问题的迁移。因此，此（非常值得欢迎的）提交所提供的“两次重启”方案，很可能比直接采用边缘方案导致更长的停机时间（两次重启周期）。
我目前的想法是，更好的解决方案是让引导过程始终在设置 SKIP_POST_DEPLOYMENT_MIGRATIONS=1 的情况下执行迁移，然后在首次启动时再执行迁移。不过，我还没有一个优雅的解决方案来具体实现这一点。有没有快速判断是否有待执行迁移的方法？我想引导脚本可以在启动 unicorn 之后添加一些逻辑，例如“如果有待执行迁移，则运行迁移”。但这相当繁琐，而且对大多数安装而言，在大多数情况下可能并不值得。
绝大多数情况下绝对不值得这样做，但如果你的软件升级偶尔（但有时）耗时是正常情况的 10 倍，这对许多用户来说确实是个大问题。
此后，我将至少在 Discourse 发布一周后再进行升级。当然，你可能会说我当初就不该急着升级，是我自己犯傻，我本该更清楚，这些说法完全正确！不过，让升级时间更加一致和可预测，对所有其他“犯傻”的用户来说，将是一项极好的服务。
或者，通过 docker_manager 的 UI 进行升级会自动处理此问题。
太棒了！我几乎从不通过这种方式升级，所以从未想到过这一点。谢谢。
抱歉，为了明确起见，如果我们将此环境变量添加到我们的应用容器中：
即：
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
或
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
当我们运行 launcher 时，在重建时是否会跳过所有数据库迁移？
我的理解正确吗？
不完全正确。请参阅 Introducing Post Deployment Migration
你好，我已经通过这种方法（即通过用户界面）成功更新了所有内容。但之后系统开始执行带有迁移指令的部署操作（该操作最初被跳过），随后在一段时间后失败，提示升级未成功。不过，论坛目前运行正常，管理后台也显示所有内容已更新。
我的问题是：我还需要做其他操作吗？特别是关于这个部署操作，我是否需要通过命令行运行（以避免崩溃）？是否有特定的命令？在运行过程中会不会导致论坛中断？
您还有相关的日志吗？您需要运行迁移，否则网站上的搜索功能将失效。
./launcher enter app
bundle exec rails db:migrate
没有日志，但确实是之前在本主题中提到的那些查询。
在我开始这个过程并让其运行之前，这会暂时导致网站中断（类似于重建）还是“安全”的？抱歉我坚持询问这个具体问题，但这是一个生产环境网站，10-15 分钟的停机时间可以接受，但一两天则不行，如果没有其他选择，必须慎重考虑。
如果您已升级到最新版本，运行迁移不会导致您的网站停机。所谓“已升级”，是指新版本已部署，但本主题中的部署后迁移失败。
谢谢。我最终通过 UI 回到了更新流程，再试了一次，部署后的数据库迁移实际上已经成功执行。整个过程耗时数小时（并且占用了大量 CPU 资源：sweat_smile），但现在已经全部完成，系统已完全更新！