unicornのログにredisエラーによりフォーラムが利用不可

[AxelTerizaki]

こんにちは。

私のマシンでは2つのフォーラムをホストしており、どちらも最新の状態です（一方は3.4.0.beta3-dev、もう一方は利用できないため確認できません）。

そのうちの1つは今週初めにアップデートした後、約2日前に突然動作しなくなりました。

ログインすると、すべてのページに「Oops」というメッセージが表示されます。

コンテナに入ってUnicornのログを確認したところ、Redisとの接続に問題があるようです。

Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

問題は、コンテナ内のRedisサーバーにredis-cliで接続し、キーの設定と取得は問題なくできるのに、何が間違っているのかわからないことです。

フォーラムで似たような問題が多く見られますが、古いものか、解決策が見つかっていないものばかりです。どなたか助けていただけませんか？必要であれば、さらに情報を提供できます。

[pfaffman (Jay Pfaffman)]

これは以前は機能していましたか？

いつから始めましたか？

それぞれ独自のRedisおよびPostgresテンプレートと、データへの異なるパスを持つ標準のapp.ymlファイルの2つのバージョンがありますか？

可能性の1つは権限です。ある時点で、使用されたユーザーとグループのIDが変更されましたが、シングルコンテナセットアップで問題が発生したことはありません。

[AxelTerizaki]

問題を確認していただきありがとうございます。

はい、これは3日前までは機能していましたが、今朝、コンテナ内からCLIでバックアップを実行しようとしたところ、奇妙なPostgreSQLエラーで失敗したため、データベースが何らかの形で破損しているのではないかと疑っています。これは上記のエラーメッセージとは全く関係ありませんが、8日前の正常なバックアップを（フォーラムのオーナーもそれで良いと言っています）復元して、すべてが解決するかどうかを確認したいと思います。

バックアップが現在よりも古いバージョンのDiscourseから、新しいバージョンに復元できると思いますか？（バックアップと現在のバージョンの間にアップデートがあったため。）

編集：明確にするために、2つのフォーラムは異なるyamlファイルであり、それぞれが独自のコンテナと異なるデータディレクトリで動作しています。

[pfaffman (Jay Pfaffman)]

@AxelTerizaki

奇妙なpostgresのエラーで失敗しました

バックアップで失敗しましたか、それともリストアで失敗しましたか？

奇妙なエラーを含めていただけると助かりますが、リストアで失敗したのであれば、こちらで説明されているものだと思います: Restore failing with missing chat_mention function

もしそうであれば、私の助言は待つことです。待つことが選択肢にない場合は、リストアするサイトがバックアップを作成したサイトと同じコミットを持っているか確認してみてください。

[AxelTerizaki]

バックアップにあります。

pg_dump: error: Dumping the contents of table "posts" failed: PQgetResult() failed.
pg_dump: error: Error message from server: ERROR:  could not open file "base/16384/17044": No such file or directory

だから、まずバックアップを復元して問題が解決するかどうか試してみると言ったのです。

[pfaffman (Jay Pfaffman)]

それはデータベースの問題のようですね。

ファイルシステムのバックアップを復元したことはありますか？データベースが実行中にファイルシステムのバックアップを作成した場合に発生するようなことですね。それが、ファイルシステムのバックアップをお勧めしない理由の一つです。

通常お勧めするDiscourseのバックアップを復元したい場合は、データベースを削除し、空のデータベースを作成して移行してから復元する必要があります。

[AxelTerizaki]

データベースのファイルシステムバックアップを行っていますが、PostgreSQLデータベースはダンプしているため除外しています。しかし、Discourseのフォルダを除外するのを忘れた可能性があるため、後で確認する必要があります。

こちらのスレッドの情報は、私のユースケースでもまだ有効でしょうか？

[pfaffman (Jay Pfaffman)]

バックアップを必要な場所に配置する方法についての説明は、不必要に複雑に思えます。

[AxelTerizaki]

わかりました、原因を突き止めました。ファイルシステムに関する正しい方向性を示していただきありがとうございます。ウイルススキャンを実行したところ、フォーラムにウイルスシグネチャを持つ何かがアップロードされていたことが判明しました。その結果、ClamAV がファイルを削除しました。今後、PostgreSQL ファイルを検疫しないように、より適切に調整します。

お時間を無駄にさせてしまい申し訳ありません

[pfaffman (Jay Pfaffman)]

素晴らしい！ヒントがお役に立てて嬉しいです！まさかそんな方法があるとは思いもよりませんでしたが、私は長い間ウイルス対策ソフトを実行していませんでした。