このあたり、よさそう

>Based on your upgrade strategy, you may need to rebuild your B-tree indexes to take advantage of these improvements (for example, pg_upgrade will not automatically rebuild your indexes).

しっかし英語って文字数の割に情報量が少ねえな。段落全部を引用したかったのに、できやしねえ

Follow

アップグレードの方法にもよりますが、*性能改善の恩恵を受けたければ B-tree インデックスを再構築しないといけないかもしれません(たとえば pg_upgrade を使った場合、インデックスを自動で再構築しないので)。以前のバージョンでは、テーブルに巨大なインデックスがある場合、この再構築はかなり長いダウンタイムが必要でした。その間、テーブル内容の変更はブロックされてしまうからです。しかし、これも Postgres 12 の優れた点なんですが、REINDEX CONCURRENTLY コマンドを使えば、ダウンタイムなしで、データベースを動かしながらインデックスを再構築できるんです!

*性能改善:Postgres 12 では、インデックスの性能が格段に向上するらしい。必要なディスク容量が平均40パーセント削減されるとのこと。

日本語なら、注釈含めて余裕で段落の内容全てを書けるがな。もうちょっとがんばれよ、英語お前。事実上の国際語のくせに

うーん、やっぱり pg_upgrade じゃなくて pg_dumpall を使うか。時間はかかるけど。

理由:pg_upgrade はアップグレード前のデータファイルをそのまま使うということなので、たぶん、新旧のデータ容量は変わらない(vacuum full をしてない状態)。どうせアップグレードするなら、最小限のファイルサイズにしたい

このあたりを参照しています。

>Major PostgreSQL releases regularly add new features that often change the layout of the system tables, but the internal data storage format rarely changes. pg_upgrade uses this fact to perform rapid upgrades by creating new system tables and simply reusing the old user data files.

postgresql.org/docs/12/pgupgra

pg_dumpall を使ったアップグレード手順は、ここの 18.6.1. にあります

postgresql.org/docs/12/upgradi

ユーザーが多く、ダウンタイムを極力なくす必要があるならレプリケーションを使うのが最善だと思いますが、うちは事実上鼻毛と bot しか活動していないからダウンタイムが多少発生しようが誰も困らないという、あれ何だこの両目から流れ出る透明なしょっぱい液体は

なので、これをやるつもりです(涙を拭きながら

>The least downtime can be achieved by installing the new server in a different directory and running both the old and the new servers in parallel, on different ports. Then you can use something like:

pg_dumpall -p 5432 | psql -d postgres -p 5433

postgresql.org/docs/12/upgradi

このコマンドがそのまま使えるかは、ちょっと自信ないです。大丈夫なのかこれ

postgres 11 の載ってるサーバーに 12 を同時にインストールして色々やる手順はここにあります。この人は pg_upgrade を使っているので、pg_dumpall を使うならそのあたりの手順は差し引いて読む必要がありますが、他の点は参考になります

kostolansky.sk/posts/upgrading

さっきの

pg_dumpall -p 5432 | psql -d postgres -p 5433

このコマンドですが、ユーザー postgres で動かすこれを普通に解釈すれば、

pg_dumpall: pg12 のコマンドを、
-p 5432: ポート5432で動いてる pg11 に発行し、pg11 の全データのダンプを取る。

そしてそのデータを、

psql: pg12 のコマンドで、
-p 5433: ポート5433で動いてる pg12 の、
-d postgres: postgres という名のデータベースに突っ込む

ということになります。だから、

・シェルにログインしているユーザー名
・データベース名

を、場合に応じて適宜変更する必要がある、ということです。Mastodon を標準的な手順に従ってインストールしている場合にはどうすべきか、ちょっと考えないといけません

pg_dumpall はロール(≒ユーザー)情報もダンプしてくれるのね。じゃあ、とにかくスーパーユーザーである postgres でログインして、pg_dumpall すればいいのか

postgresql.org/docs/12/app-pg-

あー、やっぱりこれでいいのか。

pg_dumpall -p 5432 | psql -d postgres -p 5433

ただ、これだと pg_dumpall の結果をいったん保存することなく、それを次の psql コマンドの入力に問答無用でダイレクトに突っ込むという男気あふれる所作になるので、その男気についていけない場合は、パイプを使わずに

pg_dumpall -p 5432 -f dumpfile
psql -d postgres -p 5433 -f dumpfile

の二段構えで行けばいいのであろう

やっぱりまだ psql コマンドが何で postgres データベースを指定しているかが分からなかったんですが、pg_dumpall のマニュアルに、

>It is not important to which database you connect here since the script file created by pg_dumpall will contain the appropriate commands to create and connect to the saved databases.

とあるので、安心した次第です。データベース名 postgres で良いんだよ母さん!

……ここまで下調べしましたが、今日は何と言いますかこう、アップグレードする気が盛り上がってきません。どうしてしまったんでしょうか。ビール飲んでメシも食って満ち足りてしまったからでしょうか。Postgres のアップグレードにはハングリー精神が必要なんでしょうか

要するにただ怖いだけだと思います

なので、またそういう気分が盛り上がってきたら、その時に鋭意アップグレードしようかと

Sign in to participate in the conversation
Mastodon at crazynewworld.net

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!