いいアイデアですね、Edさん！投稿を更新しました。
「いいね！」 2
この変更により、メモリ使用量が約4%全体として減少しました。よくやりました。
「いいね！」 2
Lillyさん、ありがとうございます。さきほどアップグレードを実施しましたが、すべて正常に完了したようです 
「いいね！」 1
書き直されたテーブルやインデックスがはるかにコンパクトになることは珍しくありません
「いいね！」 1
うーん、あれはPostgresの運用ノイズの範囲内です（vacuumの前後やテーブル再構築などの有無によって見方が変わります）
それ以来、何かが不足しているという点には気づいていないので、私の知る限りすべて問題ないようです。
「いいね！」 1
私は /var/discourse に単一の Docker コンテナとして Discourse を実行しています。
組み込まれた PostgreSQL データベースをバージョン 15 から 18 へアップグレードしようとしたところ、アップグレードは完了したように見えますが、アクティブなデータディレクトリは現在以下のように報告しています：
/shared/postgres_data/PG_VERSION
18
しかし、再構築した Discourse コンテナには依然として PostgreSQL 15 のバイナリのみが含まれています：
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
PostgreSQL サービスは以下のように設定されています：
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
一方、実際の Discourse データディレクトリは以下にマウントされています：
/shared/postgres_data
その結果、PostgreSQL は以下のエラーで失敗します：
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
最近の Discourse Docker イメージには PostgreSQL 18 のバイナリが含まれているはずだと理解しています。app.yml を変更して PostgreSQL 18 テンプレートを使用し、アプリを再構築しましたが、生成されたコンテナには依然として PostgreSQL 15 のバイナリが含まれており、サービススクリプトもまだ /etc/postgresql/15/main を指しています。
現在のサービス設定の関連部分は以下の通りです：
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
私の質問は以下の通りです：
-
PostgreSQL 18 のバイナリが実際に含まれるように、Discourse コンテナを再構築または更新する正しい方法は何か？
-
app.ymlで使用するべき特定のテンプレートやイメージタグはあるか？ -
PostgreSQL 18 が利用可能になった後、既存の
/shared/postgres_dataディレクトリに対して起動するためのサポートされている手順は何か？
PostgreSQL 18 のデータディレクトリを削除したり再初期化したりしていません。古い PostgreSQL 15 のデータを復元するのではなく、アップグレードされたクラスタを回復したいと考えています。
「いいね！」 1
OP（スレッド開始投稿）の指示に基づいて行いましたが、何か見落としているのでなければ、これは不要な手順だったように思えます。
標準インストールを単に再構築しただけで、最新のイメージが取得され、マイグレーションが実行されるはずですから。
最新のイメージを何らかの方法で除外しない限り、新しいバイナリが確実に使用されるはずですよね。 非常に奇妙ですが…
イメージを固定（ピン留め）していないことは確かですか？
「いいね！」 3
意図的にピン留めしたわけではありません。通常のGitリポジトリとブランチを使用しており、app.ymlにピン留めを示唆するものは何もありません。PostgreSQL 18のテンプレートに変更して効果があるか試してみましたが、それは確かに効果がなかった不要な手順でしたので、元に戻すことは可能です。
新しいバイナリを取得する方法について、何か提案はありますか？何度再構築しても、本当に存在していません：
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
「いいね！」 1
時間と手間を節約するために、最新のバックアップを使用して新しいサーバーを作成することを検討することをお勧めします。そうすれば、多くの作業を省くことができます。
「いいね！」 1
わかった、たぶんそうかもね！ 修正に手間をかける価値がないこともあるから。ありがとう。
「いいね！」 2
管理パネルにアクセスできない場合、Discourseが暴走してしまい、root@経由でDBを取得して新しいインスタンスにアップロードしたいのですが、どうすればよいですか？（別のガイドがあるかもしれません）
あるいは、管理パネルで同じことを実行するのと同じことをコマンドラインで行うには、どのようなコマンドを使えばよいですか？
はい、そして本題ですが、先ほど突然発生した（予期せぬ変更はなかったにもかかわらず）証明書エラーを修正するためにアプリを再構築する必要があります。ポート443にアクセスできないというエラーが表示されており（ウィザードには「DNS検証に失敗しました」と表示されています）—— Cloudflare (CF) や DigitalOcean (DO) が何か変更したのかはわかりませんが、私の側では何も変更していません。前回のように「ディスク容量不足」ではなく、この下のエラーを含むおそらく2つのエラーが発生しているため、再構築できません。この下のエラーをどうやって乗り越えればよいのか、何かアイデアはありますか？
補足として、プライマリーディスクのサイズを拡大した前後でも、同じエラーが発生しました（Postgres 15から18への移行に必要な容量を考慮しての拡大です）。
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
ああ、分かった。このトピックのかなり前に @Lilly が投稿していたものの中に、おそらく必要だと思うものを見つけた。
cd /var/discourse
./launcher enter web_only
discourse backup
exit
これを見ると、使用可能なDBバックアップを出力でき、それを新しいDiscourseインスタンスにアップロードして、すべての問題を回避できるはずだと推測している。
このコマンドは、投稿+アップロード/画像を含む完全なバックアップを取得できるのか？
データベースのみをバックアップし、それ以外は rsync で移動することを推奨します。rsync を使って Discourse サイトを別の VPS に移動する。SSL 証明書も rsync で転送できるので、DNS を変更する前に新しいサイトを立ち上げることができます。
追記: ごめんなさい。問題が解決したのか、それともまだ解決していないのか判断がつきません。正しく理解しているなら、最も簡単な方法は、デフォルトのバージョン指定なしのテンプレートに戻して、もう一度再構築することです。
「いいね！」 2
必要とされているように、データ（おそらくあなたのケースではアプリ）コンテナを2回再構築しましたか？
（ちなみに、更新メッセージには「app」を再構築するように書いてありますが、「appやdataと呼ばれる可能性があるデータベースコンテナ」のことなのか、それとも両方のことなのか、と推測しています。）
それからフィードバックですが、少し前に13から15への移行を試みましたが、何度か失敗してしまい、結局.13のテンプレートで留まることになりました。その後、.18が提供されたので再度試してみたら、問題なく成功しました（その前に_newと_olderディレクトリをクリーンアップする必要はありましたが）。これで、デフォルトのバージョン指定なしのデータテンプレートで再び動作させることができました。更新をこれほど堅牢にしてくれたこと、素晴らしいですね。
「いいね！」 1
エラーログを確認したら、PGの更新前にSQL関連のエラーがいくつか記録されていることに気づきました：
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
奇妙なことに、この関数はPG9由来のように見えますが、私はそれまで15番を運用していました。これは権限の問題やsearch pathの問題でしょうか？DB更新後は発生していないようですが、バッチのタイミングの問題かもしれません。この関数はかなり多くの場所、さらにはマイグレーションスクリプトでも使用されているのが見えます。
もしかすると、テンプレートにはまだ記載が残っているものの、古いPostgreSQLでは一部の関数が失敗してしまうということでしょうか。見落としているかもしれませんが、古いバージョンは互換性があるはずだと思っていました。
「いいね！」 1