これはサポート対象外のプロセスですので、念のため動作テストをお勧めしますが、おそらくアップグレードを実行するだけで問題なく動作するはずです。
標準インストールとdual containerの両方でPostgreSQL 18のアップデートを実行しましたが、何の問題もありませんでした。わかりやすい手順を提供してくださった@chrisrとチームに改めて感謝します。
Cloudflare CDN背後に配置されたdual container構成で、R2のアップロード/バックアップバケットを使用する場合、私が使用した手順は以下の通りです：
ステップ1：ディスクのクリーンアップ
# 使用していないDockerデータを削除
docker system prune -a -f
# 古いログとaptキャッシュをクリア
journalctl --vacuum-time=2d
apt-get clean
apt-get autoremove -y
# データベースのサイズを確認
du -sh /var/discourse/shared/data/postgres_data
# 新しい利用可能な空き容量を確認
df -h -x tmpfs -x devtmpfs
ステップ2：メンテナンスとバックアップ
- Cloudflareのメンテナンスページを編集し、「15〜20分間のシステムメンテナンスアップデート中」と表示し、リロードタイマーを設定します（実際にはこれほど時間がかかることはありませんが、安全策として設定します）。Cloudflare Workerのルートを設定してメンテナンスページを表示します。
- コマンドラインからバックアップを実行：
cd /var/discourse
./launcher enter web_only
discourse backup
exit
- Cloudflare R2ダッシュボードにログインし、バックアップフォルダを確認してバックアップファイルが正常にアップロードされたことを確認します。
ステップ3：安全なシャットダウン
- まずWebコンテナを停止してアクティブな接続を切断し、次にデータベースコンテナを停止します：
cd /var/discourse
./launcher stop web_only
./launcher stop data
- PostgreSQLが正常にシャットダウンしたことを確認します：
tail -n 20 shared/data/log/var-log/postgres/current
ステップ4：アップグレードと再構築
以下のコマンドをこの順序で実行します：
./launcher rebuild data # PostgreSQL 18をダンプ、移行、リストア
./launcher rebuild data # データベースコンテナを再構築
./launcher rebuild web_only # Webアプリを再構築
ステップ5：最適化とクリーンアップ
- 欠落しているpg18のテーブル統計を生成します。生成しないと、フォーラムが通常より低速になります：
docker exec -u postgres data /usr/lib/postgresql/18/bin/vacuumdb -d discourse --analyze-in-stages
- フォーラムをテストして、すべてが正常に動作していることを確認します。リロードタイマーが設定されている場合、メンテナンスページはもう表示されないはずです。
- メンテナンスページへのCloudflare Workerのルートを削除します（1日10万回の制限に達したくないため！）
- 古いpg18のデータを削除して、ディスク容量を確保します：
rm -fr /var/discourse/shared/data/postgres_data_old/
完了！ 
「いいね！」 3