セルフホスティングユーザー向けPostgreSQL 18アップデート

Literate Computing ダッシュボードは、2つのスタンドアロンサイトと1つの2コンテナサイトを問題なくアップグレードしました。主に必要だったのは、変数内のターゲット PostgreSQL バージョンを変更することだけだったので、宣伝通り、プロセスは直近のアップグレードと同じでした。

実際にはかなりサポートされており、データベースのメジャーバージョンをアップグレードするよりも安全です。何か問題が発生しても、新しいサーバーに切り替えないだけです。OS のアップグレードが必要そうだったり、ダウンタイムを最小限に抑えたい場合や、これは良い方法です。新しいサーバーを構築している間は読み取り専用とし、その後切り替えます。簡単な方法では、最終的な再構築時のダウンタイムのみが発生するか、旧サーバーから証明書をコピーすればゼロダウンタイムになります。

データベースのアップグレードですべてが失敗した場合、新しいサーバーを構築してバックアップを復元するのが簡単な解決策です。

開始前に必ずバックアップを作成してください。アップロードは失われないため、データベースのみのバックアップを作成しています。

「いいね!」 4

注意:理由には確信が持てませんが、PostgreSQL 18 へのアップグレードではネイティブなデータチェックサムが無効化されます。PostgreSQL のデータチェックサムはデフォルトで有効な機能であり、これを無効にするのは非常に不自然です。

データチェックサムを無効にしないためのPR(デフォルトで有効): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub

1年に1回、1時間だけ必要になるために20GBの空き容量を確保しておかなければならないよりマシだよ、笑

もしかしたら、木や水を節約するためにはこれが推奨される方法になるべきかもしれないね。:sweat_smile:

確認ですが、私はDiscourseが提供するPostgreSQLを使用していませんし、Discourse自体はまだPG18を必要としていませんよね? つまり、私は(まだ)PG18へのアップグレードは必要ありません。

その通りですね。ただし、もう一つの理由は、LTS(長期サポート)リリースは数年に一度しか行われないため、そのタイミングでまとめて行うのは悪くないアイデアだということです。

確かにまだ時間があります。ある特定の機能が必須だったため、アップデート直後にかなり速くあるリリースを推奨しましたが、おそらく1年ほど待っても問題ないでしょう。私はdiscourse_dockerリポジトリをウォッチしています。いずれPG15のサポートを削除する話が出始めますが、特に騒がしい話題ではなく、内部の更新状況を把握する簡単な方法です。

「いいね!」 2

私のPi 5のインストールでは問題なく動作し、2回の再構築で完了しました。

「いいね!」 4

ちなみに、ベンチマークはありますか?

あれば、他の人も私たちの勇敢な足跡を早く追ってくださるかもしれません。

私の無料のWeb検索AIによると、以下のようです:

典型的なRailsアプリの場合、PostgreSQL 15から18への移行により、コードを変更せずに約10~25%のクエリパフォーマンス向上が期待できます。また、新しいインデックス機能やプランナーの機能を活用すれば、特定のクエリパターンでは**最大40%**の向上も見込めます。

もしこれが本当なら、かなり大きなアップグレードですね! :tada:

「いいね!」 1