Postgres 12に関する議論がアップグレードを壊す

サポート インストール
1

Discourse の v13 へのアップグレードにはディスク容量が不足するため、現在は PostgreSQL v12 を稼働させています。v12 との互換性が壊れているようですが、これは意図的なものでしょうか？もしそうであれば、Discourse を今後二度とアップグレードできなくなってしまいます。

./launcher start app を実行してサービスを再開しましたが、現時点では本番環境の問題ではありません。しかし、セキュリティ対策などの理由でさえアップグレードできない状態は、我々にとって非常に深刻な問題です。

app.yml の内容：

  - "templates/postgres.12.template.yml"

./launcher rebuild app を実行した結果：

FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Location of failure: /pups/lib/pups/replace_command.rb:8:in `read'
replace failed with the params {"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** FAILED TO BOOTSTRAP ** 上記のログをスクロールして、より早期のエラーメッセージを探してください。エラーが複数ある可能性があります。
./discourse-doctor を実行すると問題の特定に役立つかもしれません。

現在稼働中のバージョンは 2.8.0.beta4 75b0d6df93 です。

2

PostgreSQL 13 を探しており、12 ではありません。

{“filename” => “/etc/postgresql/13/main/pg_hba.conf”,

3

その通りです。それが問題なのです。

4

バックアップを取得し、Postgres 13がデフォルトとなる完全に新しいDiscourseインスタンスを作成し、バックアップを復元してDNSでサーバーを再マッピングするのはどうでしょうか？

「いいね！」 2
5

それは可能ですが、極力避けたいところです。

「いいね！」 1
6

一見怖く見えるかもしれませんが、十分な安全策が講じられていますので、いつでも旧サーバーを再度オンラインに戻すことができます。

「いいね！」 1
7

「1〜2日分の投稿が失われる」とフォラムのメンバーに伝えることよりも、避けたい面倒な作業の方がマシです。できれば、Discourse の開発者たちに「もちろん PG12 版も対応しています。これは単なるバグなので、すぐに修正します」と言ってほしいものです。

8

なぜそれが必要なのか、私にはわかりません。

  1. サブドメイン上に新しいサーバーを準備する？

  2. 既存のサーバーをリードオンリーモードにし、バックアップを作成する

  3. 新しいサーバーにバックアップをインポートする

  4. DNS を再マッピングする

  5. 主要な Discourse サブドメインで新しいサーバーを再構築する

このプロセスは30分程度で終わるでしょうか？

「いいね！」 2
9

いいえ、私は非常に大規模なフォーラムを運営しています。

「いいね！」 2
10

ああ！それは嬉しい悩みですね！:slight_smile:

11

まあ、給料もらってるわけじゃないしね！:wink:

「いいね！」 1
12

ああ、コミュニティの PR で導入されたバグですね。どこでも PG12 を実行していないため、見逃されていました。数分お待ちください。

「いいね！」 5
13

Fix #551 regression on old pg by xfalcox · Pull Request #566 · discourse/discourse_docker · GitHub で修正されました。

@Wingtip さん、再度ビルドし直していただけますか？

ただし、当方は PG12 を運用していないため、コア機能に PG13 以降専用の SQL 構文を導入する可能性があります。そのため、アップグレードを「いつか」スケジュールしておくことをお勧めします。

「いいね！」 5
14

VMの別のスナップショットを取得した直後に確認します。

PGのアップグレードには大量のディスク容量が必要で、本当に腹が立ちます。OracleやMySQLではこのような問題はなく、インプレースでアップグレードできます。

15

pg_upgrade は、その場でのアップグレードを可能にする単一の --link フラグを提供します。

当社の「初心者向け」ランチャーアップグレードスクリプトでは、99% のインストールがクラウド VM 上で実行されており、ディスク容量を簡単かつ安価に拡張できるため、このフラグの使用は見送りました。

ただし、プロセス中のディスク容量を節約するために手動でアップグレードを行いたい方のために、オプションとして用意されています。

「いいね！」 1
16

2 つの解決策が提示されました。私の記憶では、一つはデータベース全体の約 3 倍の容量が必要で、もう一つは約 2 倍が必要でした。もしインプレースで実行できるのであれば、そのことを文書化すると非常に役立つでしょう。

追記：修正が成功しました。ありがとうございます！

「いいね！」 2
17

はい、考えずにコピペしてしまいました。ご指摘いただき、ありがとうございます！

「いいね！」 1
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.