j127
2023 年 2 月 27 日午前 6:03
1
新しいサーバーに200,000件の投稿があるフォーラムを移行しました。ダウンタイムを避けるため、ライブサイトは読み取り専用モードにしました。
ユーザーがインストール画面や復元中に発生する可能性のある問題を見ないように、バックアップを別のサブドメインに復元しました。例えば dev.example.com のようなものです。
復元が完了したらすぐに、DNSを新しいサーバーに向け、app.yml ファイルのドメインを通常の forum.example.com に変更しました。
すると、元の投稿のすべてのスマイリーが dev.example.com サーバーを指していたため、rake:rebake を実行しました。
1,000〜2,000件の投稿を処理すると、データベース接続に関するエラーでクラッシュします。
以下にいくつかの抜粋を示します。
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:34:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:28:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:45:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:33:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
1999 / 200968 ( 1.0%)
Failed to rebake (topic_id: 78730, post_id: 210607)
PG::ConnectionBad: PQsocket() can't get socket descriptor
/var/www/discourse/lib/tasks/posts.rake:108:in `rebake_posts_all_sites'
/var/www/discourse/lib/tasks/posts.rake:7:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Caused by:
PG::ConnectionBad: PQsocket() can't get socket descriptor
現在、dev.example.com ドメインを forum.example.com ドメインにリダイレクトすることで画像を読み込めるようにしていますが、これは一時的な解決策です。
このエラーを回避してすべての投稿をリベイクする方法を知っている人はいますか？データベースに過負荷がかかっているのでしょうか？
「いいね！」 1
pfaffman
2023 年 2 月 27 日午後 2:40
2
まず、ドメイン名を変更またはDiscourseの名前を変更する を参照してください（ただし、別の解決策として、バックアップしてから新しいホスト名で復元することもできます）。
データベースへの接続が不足していることが原因だと推測しますが、それは私が予想するエラーではありません。
これは標準的なインストールですか、それとも他のPGサーバーを使用していますか？
「いいね！」 1
j127
2023 年 2 月 27 日午後 7:13
3
リンクをありがとうございます。DigitalOceanのドロップレット（「Premium AMD」、RAM 4GB、vCPU 2基）に標準的なDockerをインストールしています。
お教えいただいたリンクの手順に従いました。設定の中に間違ったURLがいくつかあったので、それらを修正し、念のためフォーラムを再構築しました。
その後、次のようなコマンドを実行しました。
discourse remap dev.example.com forum.example.com
そのコマンドは次のようなエラーでクラッシュしました。
Error: ERROR: duplicate key value violates unique constraint "unique_post_links"
DETAIL: Key (topic_id, post_id, url)=(78821, 207117, https://forum.example.com/t/the-slug/78946/7) already exists.
そこで、言及されたURL（https://forum.example.com/t/the-slug/78946/7）にリンクしていた投稿を一時的に削除し、コマンドを再度実行したところ、クラッシュせずに動作しました。
その後、rake posts:rebakeを再度実行しました。
いくつかの投稿で次のような失敗がありましたが、処理は続行しました（これらの投稿のHTMLは手動で再構築しました）。
Rebaking post markdown for 'default'
2273 / 200996 ( 1.1%)
Failed to rebake (topic_id: 66586, post_id: 210353)
JavaScript was terminated (either by timeout or explicitly)
最終的に、次のようなエラーで11,000件の投稿に達する直前でクラッシュしました。
/usr/local/bin/bundle:25:in `<main>'
10996 / 200996 ( 5.5%)
Failed to rebake (topic_id: 76678, post_id: 200988)
PG::ConnectionBad: PQsocket() can't get socket descriptor
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.4.1/lib/active_record/connection_adapters/postgresql_adapter.rb:768:in `block (2 levels) in exec_no_cache'
サイトがダウンしているとUptime Robotから通知があったため、サーバー全体がオフラインになったようです。
このコマンドを実行するにはサーバーのパワーが足りないと思われますか？
通常、RAM使用率は80%を超えており、コマンド実行中は100%に達します。メモリが不足したのかもしれません。
Ed_S
2023 年 2 月 27 日午後 7:46
4
ローカルディスクがある場合、スワップを追加してメモリ不足を回避できます（それが問題の原因であるかどうかは関係ありません）。free は何を示していますか？ dmesg の出力に oom または memory は表示されていますか？
「いいね！」 1
j127
2023 年 2 月 27 日午後 9:41
5
Ed S:
freeは何を示していますか？
現在の表示は以下の通りです。
total used free shared buff/cache available
Mem: 3.8Gi 2.1Gi 160Mi 1.0Gi 1.6Gi 488Mi
Swap: 0B 0B 0B
oom は表示されませんが、メモリの予約や解放に関する箇所で memory という単語が数回表示されます。
サーバーは 4GB の RAM で作成されたため、Discourse は 自動的にスワップファイルを作成しませんでした 。追加する価値はあると思いますか？
Ed_S
2023 年 2 月 27 日午後 10:27
6
ディスク容量に余裕があれば、スワップを2G追加する価値は間違いなくあります。
もう一つは、大きなジョブを実行中に使用状況を監視することです。vmstat 5 5 を使用し、ファイルにログを記録することも検討してください。siまたはsoの列に大きな値が表示されず、swpd列がスワップサイズに近づかないことを期待しています。
この投稿も参照してください。
（データベースシステムが何らかのリソースを使い果たしている可能性がありますが、それについては何も知りません。）
「いいね！」 1
j127
2023 年 2 月 27 日午後 10:30
7
ありがとうございます。後で試してみます。現在50GB空きがあります。
j127
2023 年 2 月 28 日午前 7:15
8
2GBのスワップファイルを追加したところ、問題が解決したようです。リベイクはまだ20%しか完了していませんが、エラーは一度も発生しておらず、RAM使用率は100%を下回っています。
お二人とも、ご協力ありがとうございました。
「いいね！」 2
j127
2023 年 2 月 28 日午後 6:03
10
そうしようかと思いましたが、サーバーをシャットダウンしなければならず、サーバーを移動した際にユーザーはすでに迷惑な「読み取り専用」期間とダウンタイムを経験していました。
昨夜は寝なければならなかったので完了できませんでしたが、今は再び稼働しています。エラーなしでこれまでのところ30%完了しました。
「いいね！」 1
Ed_S
2023 年 2 月 28 日午後 6:12
11
vmstat やそれに類するもので監視を続けるとよいでしょう。これは非常に長時間実行されるジョブなので、再起動したくはないはずです。念のため、さらに 2G のスワップを追加することをお勧めします。
「いいね！」 1
j127
2023 年 2 月 28 日午後 11:55
12
ありがとうございます。時々 vmstat で確認しました。tmux セッションで起動したので、デタッチしてラップトップをしばらく閉じることができました。コマンドの実行には 8 ～ 9 時間かかったと思われますが、すべてエラーなく完了しました。
「いいね！」 2
system
2023 年 3 月 30 日午後 11:56
13
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
