pg_repackについて調べてみた

Posted at 2020-12-22

これは、PostgreSQL Advent Calendar 2020の22日目の記事となります。

私は開発エンジニアとしてPostgresqlを利用しているのですが、
悩みごとをPostgresqlのコミュニティに相談させていただいた時に教えていただいたツールpg-repackを紹介させてもらいます。

pg-repackはテーブルの再編成を行えるPostgreSQLの拡張ツールです。
PostgreSQL Advent Calendar 2015で既に一度、中の人が直々に書かれた記事運用で役立つツールpg_repackのご紹介もあるのですが、
最近の状況も含め、改めて紹介できればと思います。

テーブルの再編成を行う方法としてVACUUM FULLコマンドなどがありますが、テーブルのに排他ロックがかかり、しかも実行に長い時間がかかるなど、リリース時の対応に頭を悩ませることになります。

私の場合、データクリーニングのために稼働中のDBに大量のUPDATEをかけた結果、不要領域が一度に増えすぎてパフォーマンスが低下したことがありました。
大量のUPDATE・DELETEがもたらす影響についてはPostgreSQLアンチパターン：UPDATEの濫用が分かりやすくまとまっています。

不要領域が著しく増えた時にはVACUUM FULLコマンドでテーブルの再編成を行う方法がありますが、長時間の排他ロックがかかるためリリース時の対応に頭を悩ませることになります。

その点pg-repackはごく短い間しか排他ロックをかけないため、稼働中のサービスに対するリリース戦略として有効な手段となります。

2020年12月時点でのバージョン情報です。

公式サイトURL	https://reorg.github.io/pg_repack/
最新バージョン	pg_repack 1.4.6
Postgresql対応バージョン	PostgreSQL 9.4, 9.5, 9.6, 10, 11, 12, 13

最新バージョンのリリース日付は2020年9月30日と、着々と開発が進んでいるようです。
また、公式サイトを日本語訳ページで見ると、対応バージョンが9.6までしか表示されない点に注意です(上記reorgの原文ページのReleaseで対応状況が確認可能)。

既に何度か書きましたが、pg_repackはテーブルの再編成を行うツールです。
ただ、再編成の方法についてはいくつかバリエーションがあります。

・オンラインCLUSTER(テーブルデータを物理的にINDEX順で並び替え)
・指定カラムでレコードを並び替える
・オンラインVACUUM FULL (レコードのすきまを詰める)
・指定テーブルのインデックス再構築・再配置

コマンドはpg_repack...[SCHEMA_NAME]の形式で、
...の部分にオプションをつけることで再編成の方法や対象テーブルを指定できます。

・スキーマ全体にCLUSTER・VACUUM FULLを実行
(クラスター化テーブルへはCLUSTER,非クラスターテーブルへはVACUUM FULLを実行)

pg_repack test_schema

・カラムを指定してレコードを並び替え(カラム指定のCLUSTER)

# -o 整列に使うINDEXカラム指定
pg_repack -o role_id -t user test_schema
# カラムは複数指定可能
pg_repack -o role_id,id -t user test_schema

・テーブルを指定してVACUUM FULLを実行

# -n VACUUM FULL指定オプション
pg_repack -n -t foo test_schema
# 複数テーブルを指定することも可能
pg_repack -n -t foo -t bar test_schema

・指定したテーブルのインデックス再編成

# -x
pg_repack -x -t users test_schema

・コマンドを実行内容を確認したい(Dry Run)

# -N 実施内容をメッセージとして出力
pg_repack -N test_schema

・再編成にはテーブルとインデックスを合わせたデータサイズ2倍の空き領域が必要
・pg_repackを実行できるのはスーパーユーザのみ
・再編成の内容によっては対象テーブルに主キーorNOT NULL+ユニーク制約をもつインデックスが存在している必要あり

本来ならハンズオン的な内容を書きたかったのですが・・・、
恥ずかしながら、インストールでつまづいてしまい、試したことを書くことができませんでした。
今後、試した結果を記事にできたらと思います!

また、レベルの高い記事にビビリつつも、なんとか投稿する勇気がなくなる前に記事を投稿することができました。
これもPostgresqlコミュニティの温かさのお陰です。

明日はsawada_masahikoさんの投稿です!