データベースのシャットダウンが遅いため、再構築に問題が発生

インストール
1

この推奨アップグレードは失敗し、フォーラムをダウンさせた後、復旧させることができませんでした。現在、discourse-doctor を実行して修復を試みており、それも失敗した場合は VM スナップショットを取得しました。

出力:

2023-04-19 18:28:31.298 UTC [42] LOG:  received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG:  shutting down
2023-04-19 18:28:33.974 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap failed with exit code 2
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps
2

ベータ版を使用していますか？

コンテナを再起動してみてください。

./launcher start app

ただし、これは discourse-doctor が行うべきことです。

エラーは含めた内容よりも上にあるため、さらに多くの出力を提供する必要があります。

「いいね！」 2
3

はい、ベータ版です。常に nohup の中で実行しているので、完全なログがあります。

Discourse-doctor はまだ処理中ですが、まだ失敗していないので希望はあります。

https://pastebin.mozilla.org/iw2zc5zd

編集: Discourse-doctor で復旧しました。

これは基本的に私が求めたもので、通知の1時間後にアップグレードし、最初に実行したのが私でした。事前にスナップショットを取得するのに大きなストレスはなかったので、ここでチームのために引き受けました。

「いいね！」 1
4
  • 2023-04-19 18:28:26.755 UTC [45] LOG: データベースシステムが適切にシャットダウンされませんでした。自動リカバリを実行中です。

データベースが60秒以内に安全に停止できない場合（ディスクが遅い大規模データベースではよく発生します）、この状態になり、5秒以内にリカバリできないと再構築に失敗します（大規模/低速なためまれですが）。

これはここに記載されている変更とは全く関係なく、Discourseでは2016年以降の問題です。

「いいね！」 6
5

ああ、ありがとう。私たちのフォーラムのような大きなフォーラムでは、もっと長く待つべきかもしれません。DBプロセスを強制終了すると、再起動後にトランザクションのロールバックが必要になり、非常に時間がかかる可能性があります。

ベータ版に関する用語はやや紛らわしいです。管理ダッシュボードにはベータ版を実行していると表示されていますが、他に確認すべき場所はありましたか？私の理解では、リリース発表で安定版の使用を推奨しないと述べられていたため、ベータ版がDiscourseには推奨されているということです。

「いいね！」 1
6

デフォルトは actually tests_passed で、これは本番環境対応とみなされます。

「いいね！」 1
7

データベースのサイズはどのくらいですか？SSDにありますか？RAMはどのくらいありますか？

別のデータコンテナを使用すると、データベースの再起動回数を減らすことができます。

8

安全なシャットダウンのために60秒が決定されたのはいつですか？現在、通常よりもはるかに大きいインストールは何件ありますか？

理想的には、この60秒の待機は、制限付きのクローズドループ待機であるべきです。現在、脆弱なインスタンスが多数存在する場合、制限は高くなるべきです。

「いいね！」 2
9

SSDで105GB、VMは16GB、PostgreSQLには8GBのバッファプールを割り当てました。

10

2016年まで遡ると、少なくともそのように見ました。しかし、状況は変わりました。 編集：ここに新しいコミットがあります。

標準的なインストールではそれほど多くないと思います。これはほぼ最初からこのようになっています。

ええ、それは大きなデータベースです。RDSまたは少なくとも別のコンテナにない、それほど大きなデータベースを持っている人はほとんどいないと思います。おそらく2コンテナインストールに切り替えることを検討すべきです。

「いいね！」 1
11

検討します。切り替え方法は文書化されていますか？また、60秒タイマーを増やすだけでは得られない他の利点はありますか？

12

昨日10分に増やしました

「いいね！」 4
13

素晴らしい、2016年に彼が元のコミットを投稿していたと仮定していました。では、私たちにとって何か利点はありますか？

14

Move from standalone container to separate web and data containers を参照してください。

古いコンテナを実行したまま、新しいコンテナを構築できます。新しいコンテナを構築するためにデータベースをシャットダウンする必要はありません。

Postgresをシャットダウンするための10分間のウィンドウができました。これにより、現在の問題が解決されるはずです。さらに1回再構築すると、1分ではなく10分になります。

15

あの男は完全に新しい2つのコンテナインスタンスを構築し、バックアップから復元しました。私たちは正当な理由なしにそれを行うことは絶対にありません。私は2ヶ月前にPG13のアップグレードディスク容量の要件を回避するためにそれを行う必要がありました。

16

PG13にまだ登録していない場合は、登録を修正する必要があります。

新しいサーバーを起動して、そちらに移行することをお勧めします。

17

それは避けられないものでした！DB以外にも、サポートが終了した18.04LTSからのアップグレードも必要でした。

「いいね！」 1
19

これほど大きなデータベースの場合は、専用のコンテナに移動することをお勧めします。

これにより、再構築が大幅に高速化され、すべてがシンプルになります。

「いいね！」 1
20

もし、完全にスクラッチから再構築することなく、それを実行する方法に関するドキュメントがあれば、バックアップを復元することを検討します。

21

Webとデータコンテナを素早く分離して移行するにはどうすればよいですか？

「いいね！」 1