2.6.0b2 アップグレードが非常に遅い

そうだと思いますよ :smiley::smiley::smiley:

「いいね!」 2

この PR がマージされるまで待ち、その後、以下の手順に従ってください:

「いいね!」 3

:smiley: :+1:

約100GB :sunglasses:

:+1: 実行します

「いいね!」 2

さて、このアップグレードの自動化を検討しているのですが、いつ「デプロイ後のスキップ」を行うべきかという判断が結構複雑だと気づきました。

単一コンテナのインストールの場合、奇妙なマイグレーションが発生しない限り(私の 4 年間の経験ではこれが初めてです)、この方法で行うメリットはありません。ほとんどのアップグレードではマイグレーションは少なく、計算集約的なものはおそらく存在しません。

2 つのコンテナを使用するインストールの場合、SKIP_POST_DEPLOYMENT_MIGRATIONS を設定するのが常に賢明です。もしマイグレーションが実行中のコンテナを壊した場合、サイトを無効化できるため、古いコンテナが稼働している間に新しいコンテナをブートストラップできるという利点の喜びが一部損なわれます。しかしそれでも、すべてのアップグレードにシステムを壊すようなマイグレーションが含まれているわけではありません。そのため、この(非常に歓迎すべき)コミットによって提供される「2 回の再起動」ソリューションは、単にエッジを攻める場合よりも、むしろダウンタイム(再起動サイクルが 2 回)が増える可能性があります。

私の現在の考えでは、より良い解決策は、ブートストラップが常に SKIP_POST_DEPLOYMENT_MIGRATIONS=1 を設定してマイグレーションを実行し、その後、初回起動時にマイグレーションを行うことです。ただ、それがどのように実現できるかについて、エレガントな解決策はまだ思いついていません。マイグレーションが保留中かどうかを素早く確認する方法はありませんか?おそらく、unicorn を起動した直後に、ブートスクリプトで「もしマイグレーションが保留中なら、マイグレーションを実行する」という処理を追加すればよいのでしょう。しかし、それはかなり細々とした作業であり、多くのインストールにおいて多くの場合、その価値はないかもしれません。

「いいね!」 2

確かに、ほとんどの場合はやる価値はありません。しかし、ソフトウェアのアップグレードがまれに(それでも時々)通常よりも10倍も時間がかかる場合、それは多くのユーザーにとって深刻な問題です。

これ以降、Discourseのアップグレードはリリースから少なくとも1週間経過するまで実行しません。もちろん、最初から待たなかった自分がバカだったと言えるかもしれません。自分で招いた結果だし、もっと分かっていたはずだ、という指摘はすべて完全に正しいです!それでも、アップグレード時間をより一貫性があり予測可能にすることは、他の「バカ」たちにとって大きな助けになるでしょう。

「いいね!」 2

あるいは、docker_manager を通じた UI からのアップグレードでも、これが自動的に処理されます。

「いいね!」 7

素晴らしいですね!私はほとんどその方法でアップグレードしたことがないので、思いもよりませんでした。ありがとうございます。

「いいね!」 2

すみません、明確にするために確認させてください。アプリコンテナにこの環境変数を追加した場合:

以下のいずれかです:

SKIP_POST_DEPLOYMENT_MIGRATIONS: true

または

SKIP_POST_DEPLOYMENT_MIGRATIONS: 1

ランチャーを実行すると、再構築時にすべてのデータベースマイグレーションがスキップされるのでしょうか?

この理解で正しいでしょうか?

もう少しです。Introducing Post Deployment Migration をご覧ください。

「いいね!」 7

こんにちは、この方法(つまり UI を通じて)ですべてを正常に更新できました。しかし、その後、以前からスキップされていた移行手順を含むデプロイ処理が始まり、しばらくしてエラーが発生し、「アップグレードが成功しませんでした」と表示されます。ただし、フォーラムは正常に動作しており、管理ダッシュボードではすべてが更新済みとして表示されています。

質問です:他に何か行う必要がありますか?特にこのデプロイ処理については、クラッシュを避けるためにコマンドラインで実行する必要がありますか?それに特化したコマンドはありますか?また、実行中はフォーラムが利用できなくなりますか?

「いいね!」 1

関連するログはまだ残っていますか?検索機能がサイト上で機能しなくなる前に、マイグレーションを実行する必要があります。

./launcher enter app
bundle exec rails db:migrate
「いいね!」 2

ログはありませんが、このトピックで以前に言及されたのと同じクエリです。

この処理を開始して実行に移す前に、一時的にウェブサイトが停止しますか(再構築のように)?それとも「安全」でしょうか?この特定の点について繰り返し申し訳ありませんが、これは本番環境のウェブサイトです。10〜15 分のダウンタイムは許容範囲ですが、1〜2 日は許容できません。他に選択肢がない場合は、慎重に検討する必要があります。

「いいね!」 1

すでに最新バージョンにアップグレード済みの場合、マイグレーションを実行してもサイトはダウンしません。ここで言うアップグレードとは、新しいバージョンがデプロイされたものの、このトピックで説明するデプロイ後のマイグレーションが失敗した状態を指します。

「いいね!」 3

ありがとうございます。結局、UI を通じてアップデートに戻り、もう一度試したところ、デプロイ後のデータベースマイグレーションが実際に完了しました。数時間(そしてかなりの CPU 使用率 :sweat_smile:)かかりましたが、無事に完了し、すべてが完全に更新されました!:star_struck:

「いいね!」 6

このトピックは最後の返信から30日後に自動的に閉鎖されました。新しい返信は受け付けられません。