# 2.6.0b2 升级非常慢 **URL:** \ **Category:** Self-hosting\ **Created:** [2020年八月21日 00:58 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604 "2020-08-21T00:58:18Z")\ **Posts on this page:** 15\ **Page:** 2
**Author:** ![michaeld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaeld/32/1594_2.png) [@michaeld](https://meta.discourse.org/u/michaeld)\ **Post date:** [2020年八月22日 09:29 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/25 "2020-08-22T09:29:02Z")
> [@Paracelsus](#): > > 我们有 600 万条帖子 我觉得他们确实有 😃😃😃 ---
**Author:** ![jomaxro](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jomaxro/32/126216_2.png) [@jomaxro](https://meta.discourse.org/u/jomaxro)\ **Post date:** [2020年八月22日 10:34 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/26 "2020-08-22T10:34:04Z")
> [@Paracelsus](#): > > 肯定有更好的方法来完成这次更新。 等待此 PR 合并后，请按照以下步骤操作： > [@2.6.0b2 upgrade VERY slow](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/20?u=jomaxro): > > Good idea, I went and implemented that: ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年八月22日 11:01 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/27 "2020-08-22T11:01:57Z")
> [@michaeld](#): > > > [@Paracelsus](#): > > > > 我们有 600 万条帖子 > > 我觉得他们确实有 😃😃😃 😃 👍 大约 100GB 🕶 > [@jomaxro](#): > > 等待此 PR 合并后，按照列出的步骤操作： 👍 好的 ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2020年八月22日 16:55 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/28 "2020-08-22T16:55:44Z")
因此，在思考如何自动化此升级过程时，我意识到确定何时执行“跳过部署后迁移”这一操作相当复杂。 对于单容器安装，除非存在某种奇特的迁移（在我四年的经验中，这是我首次听说），否则采用这种方式并无优势。大多数升级涉及的迁移很少，甚至可能没有计算密集型迁移。 对于双容器安装，始终建议设置 `SKIP_POST_DEPLOYMENT_MIGRATIONS`。这样，如果迁移导致运行中的容器出现问题，您可以禁用站点，从而减少“在旧容器继续运行的同时引导新容器”这一功能带来的部分风险。但即便如此，并非每次升级都包含会导致问题的迁移。因此，此（非常值得欢迎的）提交所提供的“两次重启”方案，很可能比直接采用边缘方案导致更长的停机时间（两次重启周期）。 我目前的想法是，更好的解决方案是让引导过程始终在设置 `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` 的情况下执行迁移，然后在首次启动时再执行迁移。不过，我还没有一个优雅的解决方案来具体实现这一点。有没有快速判断是否有待执行迁移的方法？我想引导脚本可以在启动 `unicorn` 之后添加一些逻辑，例如“如果有待执行迁移，则运行迁移”。但这相当繁琐，而且对大多数安装而言，在大多数情况下可能并不值得。 ---
**Author:** ![Wingtip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/wingtip/32/102039_2.png) [@Wingtip](https://meta.discourse.org/u/Wingtip)\ **Post date:** [2020年八月22日 18:06 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/29 "2020-08-22T18:06:32Z")
绝大多数情况下绝对不值得这样做，但如果你的软件升级偶尔（但有时）耗时是正常情况的 10 倍，这对许多用户来说确实是个大问题。 此后，我将至少在 Discourse 发布一周后再进行升级。当然，你可能会说我当初就不该急着升级，是我自己犯傻，我本该更清楚，这些说法完全正确！不过，让升级时间更加一致和可预测，对所有其他“犯傻”的用户来说，将是一项极好的服务。 ---
**Author:** ![tgxworld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgxworld/32/106117_2.png) [@tgxworld](https://meta.discourse.org/u/tgxworld)\ **Post date:** [2020年八月24日 01:12 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/30 "2020-08-24T01:12:19Z")
> [@pfaffman](#): > > 我认为（尚未测试），使用同样的技巧也能在单容器安装过程中最大限度地减少停机时间。如果我的判断正确，操作步骤如下： > > - 在你的 `app.yml` 中添加 `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` > - 运行 `./launcher rebuild app` > - 运行 `./launcher enter app` > - 运行 `SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate` 或者，通过 [docker\_manager](https://github.com/discourse/docker_manager) 的 UI 进行升级会自动处理此问题。 > ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2020年八月24日 03:23 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/31 "2020-08-24T03:23:20Z")
> [@tgxworld](#): > > 或者，通过 [docker\_manager](https://github.com/discourse/docker_manager) 的 UI 进行升级可以自动处理这个问题。 太棒了！我几乎从不通过这种方式升级，所以从未想到过这一点。谢谢。 ---
**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\ **Post date:** [2020年八月24日 04:07 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/32 "2020-08-24T04:07:52Z")
> [@tgxworld](#): > > `SKIP_POST_DEPLOYMENT_MIGRATIONS` 抱歉，为了明确起见，如果我们将此环境变量添加到我们的应用容器中： 即： ```plaintext SKIP_POST_DEPLOYMENT_MIGRATIONS: true ``` 或 ```plaintext SKIP_POST_DEPLOYMENT_MIGRATIONS: 1 ``` 当我们运行 launcher 时，在重建时是否会跳过所有数据库迁移？ 我的理解正确吗？ ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2020年八月24日 04:28 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/33 "2020-08-24T04:28:04Z")
不完全正确。请参阅 [Introducing Post Deployment Migration](https://meta.discourse.org/t/introducing-post-deployment-migration/98974) ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年九月2日 16:42 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/34 "2020-09-02T16:42:33Z")
你好，我已经通过这种方法（即通过用户界面）成功更新了所有内容。但之后系统开始执行带有迁移指令的部署操作（该操作最初被跳过），随后在一段时间后失败，提示升级未成功。不过，论坛目前运行正常，管理后台也显示所有内容已更新。 我的问题是：我还需要做其他操作吗？特别是关于这个部署操作，我是否需要通过命令行运行（以避免崩溃）？是否有特定的命令？在运行过程中会不会导致论坛中断？ ---
**Author:** ![tgxworld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgxworld/32/106117_2.png) [@tgxworld](https://meta.discourse.org/u/tgxworld)\ **Post date:** [2020年九月3日 01:08 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/35 "2020-09-03T01:08:41Z")
您还有相关的日志吗？您需要运行迁移，否则网站上的搜索功能将失效。 ```plaintext ./launcher enter app bundle exec rails db:migrate ``` ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年九月3日 08:54 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/36 "2020-09-03T08:54:12Z")
没有日志，但确实是之前在本主题中提到的那些查询。 在我开始这个过程并让其运行之前，这会暂时导致网站中断（类似于重建）还是“安全”的？抱歉我坚持询问这个具体问题，但这是一个生产环境网站，10-15 分钟的停机时间可以接受，但一两天则不行，如果没有其他选择，必须慎重考虑。 ---
**Author:** ![tgxworld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgxworld/32/106117_2.png) [@tgxworld](https://meta.discourse.org/u/tgxworld)\ **Post date:** [2020年九月4日 01:18 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/37 "2020-09-04T01:18:30Z")
如果您已升级到最新版本，运行迁移不会导致您的网站停机。所谓“已升级”，是指新版本已部署，但本主题中的部署后迁移失败。 ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年九月4日 18:48 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/38 "2020-09-04T18:48:22Z")
谢谢。我最终通过 UI 回到了更新流程，再试了一次，部署后的数据库迁移实际上已经成功执行。整个过程耗时数小时（并且占用了大量 CPU 资源：sweat\_smile），但现在已经全部完成，系统已完全更新！🤩 ---
**Author:** ![jomaxro](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jomaxro/32/126216_2.png) [@jomaxro](https://meta.discourse.org/u/jomaxro)\ **Post date:** [2020年十月4日 18:53 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/39 "2020-10-04T18:53:58Z")
此主题在最后一次回复后 30 天自动关闭。不再允许新回复。 [上一頁](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604.md?page=1)