Postgresの問題...また！

サポート インストール
1

こんにちは、Discourse を停止して再起動する際に、2 つの大きな問題が発生しています。

最初の問題
停止と再起動を2〜3回行うと（./launcher stopでもPortainer経由での停止でも関係なく）、コンテナが再起動できず、「rm: cannot remove ‘/shared/nginx.http.sock’: Is a directory」というメッセージで無限に停止してしまいます。（socketは「shared」ディレクトリではなく「shared/standalone」に存在することに気づきました。これは単なるメッセージの誤りでしょうか?）
私にはまだ理由が不明ですが、このsocketが停止後にディレクトリ化しているようで、テンプレートがsocketを削除できずにディレクトリとして扱って削除に失敗しているようです。手動で削除しても意味がなく、毎回再出現してしまいます。

2番目の問題
./launcher rebuild appを実行すると、「PANIC could not locate a valid checkpoint record」の後に「FATAL: the database system is starting up」で停止してしまいます。この問題について調べた限り、私が試したすべての方法の中で唯一機能した「解決策」は、Discourseディレクトリとその中身をすべて削除して再度セットアップし直すことでした…もちろん、これは本当の解決策ではありません！

どうやら、Discourseコンテナを停止すると、データベースが不良状態になり、「is starting up」というメッセージが表示されて再開できないようです。おそらく何かを修復しようとしているのでしょう。しかし、この問題は停止と再起動を繰り返すうちに発生するようですが、いまだに解決方法が見つかりません。

何か手がかりはありませんか？Postgresが問題を修復する方法はありますか？

2

いいえ、誤りではありません。このファイルはコンテナにマウントされるボリューム内にあります。そのため、コンテナ内とコンテナ外という視点の違いによってパスが異なります。

これは、コンテナが正しく停止されなかった場合に発生します。PostgreSQL は正常にシャットダウンするためにある程度の時間が必要ですが、当社のランチャーコマンドで停止した際にはその処理が行われます。ただし、インスタンスが十分に大きい場合や、実行中のトランザクションが多すぎる場合、データベースが受け取った期限内で正常に停止できなくなる可能性があります。

3

しかし、ホストファイルシステム上の「shared/standalone」にも「nginx.http.sock」が作成されているのを確認しました。最初はソケットとしてピンク色でしたが、しばらく経つか（停止後など）、ディレクトリとして青色に変わります。その結果、コンテナはソケットを削除しようとしてフリーズし、起動に失敗します。ソケットがディレクトリに変わってしまうのです。

では、これを修正するために何ができるでしょうか？これまで私は実験的に試していましたが、数百人のユーザーが接続し、数十万件の投稿がある状態でオンライン化する場合、Postgres が急な中断に対応できないだけで、すべてを失うリスクがあるのでしょうか？破損したデータベースを修復するための対策が必要になるでしょう。Discourse は外部の PostgreSQL で動作させることは可能でしょうか？そうすれば、Discourse コンテナが起動しなくても、データベースを管理できます。要するに、「PANIC」や「FATAL」が発生した場合、何らかの修復手段があるはずです…

4

将来的な問題解決のために、Discourse に接続された「コンテナ化」された Postgres を設定し、Discourse を停止してもデータベースを破損させない（少なくとも Discourse が停止中でもメンテナンスを実行できる）ことを目指しています。