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

もう少し詳細を教えていただけますか?私も同じ問題に遭遇しています

「いいね!」 1

同じ問題に遭遇している方のために、私が行った手順の要約(AI生成)を以下に示します:
PG15を一時的に起動 → データベースをダンプ → PG18を使用 → ダンプをリストア

「いいね!」 1

つまり、このアップグレードはイメージベースですね。

つまり、Discourse の旧バージョンのインストールを選択した場合でも、イメージは依然として18へのアップグレードを強制するのでしょうか?

わかりました。

「いいね!」 1

修正されたようですが、ChatGPT が提案した方法はエラーを修正したものの、データベースを完全に消去してしまいました。つまり、アカウント、トピック、投稿がすべてなくなりました。

幸いにも、比較的新しい開発者向けフォーラムだったので、大きな損失にはなりません。

「いいね!」 2

今日このようなことが起きないよう、細心の注意を払いました。各ステップの後に、何も削除されないという確認が表示され、不要なデータを削除する前に、すべてのデータが移行されたことを三重に確認したという印象を受けました。

しかし、もし何かが誤って実行されても、失われるデータはテーマコンポーネントの設定のみでした。

「いいね!」 1

こんにちは。私のフォーラムにはかなり大きなデータベース(約80GB)があります。バージョン13から15への移行にあたり、サーバーを変更し、新規インストールとリストアを行いました。
同じ移行方法をお勧めしますか?(アップグレードを試みましたが、照合順序のエラーが発生しました)

このトピックの前半で、スタッフは以下のように述べていました:

したがって、それは選択肢の一つです。

あなたはすでに以下のように述べていました:

照合順序のエラー?既存の Discourse のバージョンは何ですか?

遭遇したエラーやコンソール出力を投稿してみてください。

しかし、スペースが不足しませんでしたか(既存のデータベースサイズの 2 倍を推奨)?

やあ、スペースは十分あるよ(250 GB 空き)。エラーは「照合順序の不一致」だったけど、app.yml ファイルに UTF 文字列が含まれていないんじゃないかと思う。

「いいね!」 1

discourse_docker イメージでは合理的なデフォルト値を提供するように努めていますが、あらゆる使用ケースに対応することは不可能です。もし希望があれば、イメージをカスタマイズしてバージョンを固定することも自由に行えます。

ある程度、依存関係のバージョンは当社のホスティング要件を反映しています。つまり、内部でベースイメージを使用しているということです。これにより、イメージが古くなりすぎることは防げますが、同時にメンテナンスできる組み合わせには限りがあります。

より慣れ親しんだ方法であれば、完全に有効な手法です。

警告が古いデータベースのダンプ準備中に生成された場合、心配する必要はありません。pg_dump を実行する目的で、古いデータディレクトリに対してサーバーを実行しているだけです。ダンプが新しいサーバーに復元されると、インデックスは再作成されます。

この警告が表示される理由としては、過去数日以内に Debian Bookworm から Trixie へアップグレードし、glibc のバージョンを変更する新しいベースイメージのバージョンをリリースしたことが挙げられます。libc プロバイダーに基づくロケール(おそらくこれを使用していたと思われます)は glibc のアップグレード間で安定していません。そのため、アップグレードスクリプトが古いデータをダンプするために Postgres サーバーを起動すると、照合順序の不一致に関する警告が表示されます。

照合順序の不一致こそが、pg_upgrade を実行する代わりにダンプと復元を行う主な理由です。データベースが builtin プロバイダーを使用する C.UTF-8 を使用するようにすれば、glibc のアップグレードが照合順序に影響を与えることはなくなります。

「いいね!」 2

今夜アップグレードを実行しましたが、計画通りに進みました。同じデータベース照合順序の警告が表示されましたが、無視してよいようです。ありがとうございます。

「いいね!」 2

app.yml に以下を追加してみましたが、

app.yml
templates:

  • “templates/postgres.15.template.yml”
  • “templates/redis.template.yml”
  • “templates/web.template.yml”
  • “templates/web.ratelimited.template.yml”

アップグレードを先延ばしにしようとしたところ、次のエラーが発生しました。

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

ベースコンテナが間違っているようです。./launcher rebuild を実行しましたか?これにより git pull が実行されるはずですが、状況が変わるか確認するために git pull を直接実行してみてください。

「いいね!」 1

同じエラー

Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Status: Downloaded newer image for discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
Ensuring launcher is up to date
Launcher is up-to-date
Stopping old container

  • /usr/bin/docker stop -t 600 app
    app
    2.0.20260812-0036: Pulling from discourse/base
    Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
    Status: Image is up to date for discourse/base:2.0.20260812-0036
    docker.io/discourse/base:2.0.20260812-0036
    /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
    /usr/local/bin/pups --stdin
    I, [2026-08-25T06:22:16.249062 #1] INFO – : Reading from stdin
    I, [2026-08-25T06:22:16.274434 #1] INFO – : File > /etc/service/postgres/run chmod: +x chown:
    I, [2026-08-25T06:22:16.281650 #1] INFO – : File > /etc/service/postgres/log/run chmod: +x chown:
    I, [2026-08-25T06:22:16.287846 #1] INFO – : File > /etc/runit/3.d/99-postgres chmod: +x chown:
    I, [2026-08-25T06:22:16.293208 #1] INFO – : File > /root/install_postgres chmod: +x chown:
    I, [2026-08-25T06:22:16.299851 #1] INFO – : File > /root/upgrade_postgres chmod: +x chown:

FAILED

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1

「いいね!」 1

原因が分かったようです。

現在のベースイメージではPostgreSQL 18サーバーがインストールされていますが、postgres.15.template.ymlは依然としてPostgreSQL 15サーバーのパッケージがすでに存在することを前提としています。そのため、該当ファイルが存在する前に以下に到達し、上記のENOENTエラーが発生しています:

/etc/postgresql/15/main/postgresql.conf

PostgreSQL 15のホールドバックテンプレートが、PostgreSQLの構成を行う前にPostgreSQL 18サーバーのパッケージを削除し、PostgreSQL 15サーバーのパッケージをインストールするようにする小さなPRを作成しました:

これにより、postgres.template.ymlをpostgres.15.template.ymlに変更することでPostgreSQL 18へのアップグレードを延期するという意図された動作が復元されるはずです。

「いいね!」 4

アップデートはリリースされましたか?
いつ再試行できますか?(参考情報として)

修正をマージしました(@Ethsim2 さん、ありがとうございます!)。もう一度試してみてください。

「いいね!」 2

動作しました。ありがとうございます!

「いいね!」 2

同じサーバーに複数のコンテナを置いている方では、アップグレードは問題なく進みましたか?今週末に時間があれば、うちのサーバーもアップグレードしようと思っていますが、とりあえず様子見したほうがいいのか、ここで先に確認しようと思いました。

はい、数週間前に1台のサーバーでデュアルコンテナのアップグレードを実施しました(ロシアのサーバーでも)。問題は全くなかったですが、まず十分なディスクスペースがあることを確認してください。

「いいね!」 3

Docker外でPostgresの更新を行う人向けのヒントです。pg_upgradeで--linkオプションを使うことで、データのコピーが不要になります。データをハードリンクできます。これによりディスク容量を節約できます。

「いいね!」 2