Postgresのアップグレード、本当にスペースが限られている場合

サポート インストール
1

フォーラムの公式手順では、Postgres のアップグレードに 2 つの方法が記載されています。

  1. Discourse に任せる。この方法ではディスク容量が 3 倍 必要になります。つまり、DB が 100GB の場合、アップグレードを行うには追加で 200GB の空き容量が必要です。大規模な環境では明らかに大きな問題です。
  2. 記載されている「手動更新」手順に従う。この方法ではディスク容量が 2 倍 必要になります。つまり、DB が 100GB の場合、追加で 100GB の空き容量が必要です。これも一部の人にとって大きな問題です。

この投稿において、@Falco はハードリンクを使用してインプレースでアップグレードを行う --link オプションの利用を提案しました。彼が推奨しているdocker コンテナはこの引数をサポートしていますが、Discourse 開発者はその投稿ではこの方法の利用を推奨していません。

そこで質問です。以下のオプション 3 は採用すべきでしょうか？

  1. 以下のコマンドを実行する。これにはごく少量の追加ディスク容量しか必要ありません。つまり、DB が 100GB の場合、例えば追加で 10GB 程度で済むかもしれません。もしそうだとすれば、これは Discourse 開発者が推奨する手順でしょうか？また、実際にこれを行って成功した事例はありますか？

インプレースでアップグレードする新しいコマンド：

docker run --rm \
	-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
	tianon/postgres-upgrade:12-to-13 \
	--link

 

比較のために、新しいディレクトリへアップグレードする（容量が 2 倍必要となる）従来のコマンド：

docker run --rm \
	-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/12/data \
	-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/13/data \
	tianon/postgres-upgrade:12-to-13

追伸：本来ならその PG13 アップグレードスレッドに返信するつもりでしたが、投稿が 7 日後に削除されてしまいます。なぜそのような設定になっているのでしょうか？この件が最初に話題になった際、参考になるような多くの議論があったことは承知しています。

「いいね！」 1
2

もし誰かがやったとしても、ここでは言及されていません。ここでの指示は、できるだけ失敗しないようにし、システム管理の知識を最小限に抑えるよう努めています。ここにいる大多数の人々は、わずかな費用を節約するための方法よりも、最も安全で最も検証済みの方法を選ぶことを好みます。

もしあなたにとって動作するようなら、PostgreSQL 13 アップデートを適宜更新してください。ただし、その前に、bash が何かを知らない人に対して、その方法を実行することを推奨することに自信がありますか？その方法で彼らのデータベースが壊れ、サイトが永久に台無しになることはないという確信がありますか？

考え方は、もし他の有益な情報が提示された場合、それが一年分もの役に立たないか誤った可能性が高い投稿を読み通させるのではなく、OP（最初の投稿）に追加されるようにすることです。

「いいね！」 1
3

いいえ、確信はありません。Postgres の経験があまりないため、Discourse の開発者の誰かが、それが機能することを保証してくれることを期待していました。

仮にそれが機能したとしても、ロールバックのためにデータベースの別コピーを保持する従来の方法があるため、デフォルトのアップグレード手順として推奨はしません。しかし、それが機能するのであれば、ストレージ容量が限られた環境では素晴らしい選択肢となるでしょう。

4

もう一つ簡単な方法は、新しいサーバーを起動し、データを移行してから、古いサーバーを停止することです。もし古いサーバーを使用しなければならない場合は、一時的なサーバーでアップグレードを行い、元のサーバー（おそらくOSのアップグレードが必要）にクリーンインストールして、その後戻す方法が安全で簡単です。

これは安全で簡単、かつ文書化も十分に行われています。すでに数百人がこの方法を実践しています。

5

はい、ただしそれには1〜2日かかります。その間、ユーザーに対して「この期間の投稿は失われます」と伝えるか、あるいはフォーラムを閲覧専用モードにするかの選択肢があります。どちらの案も理想的な解決策とは言えません。

「いいね！」 1
6

サーバーがダウンするのは、再構築期間よりもずっと長くはならないと思います。もし新しいサーバーに移行してそこに滞在するなら、移行中は古いサーバーを読み取り専用モードにしておくことができます。ダウン時間が懸念事項であれば、新しいサーバーへの移行の方がはるかに、はるかに良い選択です。

「いいね！」 1
7

フォラムは結構大きいですが、バックアップの復元を試したことがないので、どれくらい時間がかかるかはわかりません。もし行うなら、新しいホストのままになるはずです。可能であれば、余計な手間や面倒を避けたいため、その方法は避けたいと考えています。

「いいね！」 1
8

はい、私が最初にここで提案した通りです Discourse on postgres 12 breaks upgrades - #8 by merefield

思い切って実行してみるのはどうでしょうか？

「いいね！」 1
9

ここでの私のすべての投稿は、それを避けるための継続的な試みでした。

10

@Wingtip さん、これアップグレードしましたか？

「いいね！」 1
11

限られたスペースでのアップグレードを解決するもう一つの方法は、バックアップを作成し、rm -rでPostgreSQLディレクトリを削除し、再構築してからバックアップを復元することです。先週、あるサイトでこの方法を実行しました。

「いいね！」 2
12

バックアップは、データディレクトリを複製するのとほぼ同じくらいのスペースを占有しませんか（圧縮も必要なので、それ以上になる可能性もありますか）？

「いいね！」 1
13

いいえ、アップグレードは一度も行っていません。DBを削除してバックアップを復元するのはかなり危険に思えます。基本的に、インプレースアップグレードを機能させる必要があります。

Ubuntu 18.04を実行していますが、これは2023年にサポートが終了するため、その時点で新しいホストに移行するしか選択肢がなくなり、その時に覚悟を決めて、22.04 LTSを実行する新しいホストを構築し、バックアップから復元することを計画しています。

14

うーん。無駄になるかもしれない。バックアップモデルを使えば、コピーの1つが圧縮されていて、それが違いを生む可能性があると思うか？そして、私がそれを実行したサイトはS3にバックアップがあった。テストサイトだったので、問題があってもリスクは低かった。

ただし、バックアップはインプレースアップグレードよりもはるかに頻繁に、より多くの状況で使用される。私はそれをはるかに安全だと考えている。

「いいね！」 1
15

しかし、PostgreSQL に関する専門知識があまりなく、自信がありません。バックアップからまったく別の VM にサイト全体を復元することはできますが、復元にかかる時間だけ投稿が失われることを意味するため、それもあまり乗り気ではありません。しかし、18.04 はサポートが終了するため、来年はあまり選択肢がありません。

「いいね！」 1
16

データベースが数十ギガバイトでない限り、数時間もかかりません。また、バックアップと復元を行う前にフォーラムを読み取り専用モードにするので、投稿を失うことはありません。ダウンタイムはほとんどなく、読み取り専用の時間だけで済むので、それほど難しいことではありません。

17 
root@forum-app:/shared/postgres_data# du -sh
97G     .

読み取り専用にするのではなく、今日の投稿は一時的なものであることを示すバナーを掲示することをお勧めします。私の見解では、投稿は失われるとしても、それについてチャットできるようにしておく方が良いでしょう。

「いいね！」 1
18

そうなれば、組み込みの Discourse チャットにもアクセスできるようになります。これは 2.9 でリリースされる機能です（おそらくデフォルトではオフですが、ベータ版で利用可能でサポートされます）。

「いいね！」 3