【テクニカル・上級編】 VACUUM FREEZEとトランザクションID周回 – PostgreSQL

PostgreSQLのトランザクションID周回（Wraparound）とVACUUM FREEZEの深淵

どうも、皆さん。データベースの奥底に潜り込むのが大好きなエンジニアです。今日は、PostgreSQLの、いや、リレーショナルデータベース全般における、ある種の「永遠の課題」とも言えるトランザクションIDの周回（Wraparound）問題と、それを回避するためのPostgreSQLのメカニズム、特に `VACUUM FREEZE` について、もう少し踏み込んでお話ししたいと思います。

教科書的な説明はもうたくさんでしょう？ここでは、現場で実際に遭遇するであろうトラブルシューティングのヒントや、内部アーキテクチャの深い部分に触れながら、皆さんのPostgreSQL運用に新たな視点を提供できればと考えています。

トランザクションID（XID）とは何か、そしてなぜ周回するのか

まず、基本から復習しましょう。PostgreSQLでは、全てのトランザクションに一意のID、つまりトランザクションID（XID）が割り当てられます。このXIDは、MVCC（Multi-Version Concurrency Control）を実現するための要であり、データの可視性判定に不可欠です。

しかし、XIDは有限です。PostgreSQLのXIDは32ビット符号なし整数で表現されるため、最大で約40億（正確には 2^32）個のトランザクションIDを割り当てることができます。問題は、このXIDが「周回」してしまうことです。つまり、最大値を超えると、再び0からカウントが始まるのです。

もし、この周回をそのまま放置してしまうと、どうなるか想像できますか？過去のトランザクションIDが、新しいトランザクションIDと重複してしまい、データの可視性判定が混乱します。例えば、ある行が「古いトランザクションAによって挿入され、コミットされた」と判断されるべきなのに、XIDが周回して「新しいトランザクションBによって挿入された」と誤って判断されてしまうと、データが消失したり、意図しないデータが表示されたりする、まさに悪夢のような状況になりかねません。

PostgreSQLは、この悲劇を防ぐために、いくつかのメカニズムを搭載しています。その中でも、最も重要かつ、時として運用担当者を悩ませるのが、VACUUM と、その特殊なモードである VACUUM FREEZE です。

VACUUM FREEZEの役割：XIDを「凍結」するということ

通常、`VACUUM` は、削除された行のバージョン（ヒープタプル）を回収し、インデックスの断片化を解消するメンテナンス作業です。しかし、`VACUUM FREEZE` は、これに加えて、古いトランザクションIDを「凍結」（freeze）するという、より根本的な役割を担います。

「凍結」とは、具体的に何を意味するのでしょうか？
PostgreSQLの内部では、各行（ヒープタプル）には、その行がいつ作成され、いつ終了したかを示すXID（`xmin` と `xmax`）が記録されています。
`VACUUM FREEZE` は、まだ凍結されていない（つまり、将来的に周回してしまう可能性のある）古いXIDを持つタプルを見つけ出し、そのXIDを XID_FREEZE_THRESHOLD（デフォルトでは `2^31`）よりも古いものとマークします。
この「凍結」されたXIDは、それ以上古くなることはなく、周回するXIDの範囲から事実上排除されます。これにより、将来的に周回してくるXIDが、凍結されたXIDと重複するのを防ぐことができるのです。

frozenxid の概念と、VACUUM FREEZEのトリガー

この「凍結」されたXIDの管理において、非常に重要な役割を果たすのが、データベース全体で管理されている `pg_class` システムカタログの `relfrozenxid` という列です。
これは、そのテーブル（リレーション）において、いつより古いXIDを持つタプルは全て凍結されているとみなすか、という閾値を示しています。
`VACUUM FREEZE` が実行されると、この `relfrozenxid` の値が更新されていきます。
さらに、データベース全体で `pg_database` システムカタログにある `datfrozenxid` という列も存在し、これはデータベース全体の凍結XIDの閾値を示しています。

さて、ではこの `VACUUM FREEZE` は、いつ、どのように実行されるのでしょうか？
PostgreSQLのバージョンにもよりますが、一般的には、`autovacuum` デーモンが、XIDの周回が現実的な脅威となり始める前に、自動的に `VACUUM FREEZE` を実行するようになっています。
具体的には、あるテーブルのXIDが XID_WRAPAROUND_THRESHOLD（デフォルトでは `2^31 – 200000`、つまり約20億）に近づくと、`autovacuum` はそのテーブルに対して `VACUUM FREEZE` を実行しようとします。

もし、`autovacuum` が十分に機能せず、この閾値を超えてしまった場合、PostgreSQLは 強制的にすべてのトランザクションを拒否し、データベースを読み取り専用モードに移行させる という、まさに最終手段に出ます。これは、XID周回によるデータ破壊を防ぐための、PostgreSQLの最後の砦です。
この状態になった場合、管理者は `VACUUM FREEZE` を手動で実行するか、あるいは `VACUUM FREEZE` を実行できる状態にするための措置を講じなければ、データベースの書き込み操作を再開できません。

パフォーマンスへの影響とトラブルシューティングのヒント

`VACUUM FREEZE` は、データベースの安定稼働に不可欠な処理ですが、その実行には当然ながらパフォーマンスへの影響が伴います。

I/O負荷: `VACUUM FREEZE` は、テーブル全体をスキャンし、タプルのXIDをチェックして必要に応じて更新するため、大量のI/Oを発生させます。特に、巨大なテーブルや、更新頻度が高いテーブルでは、この負荷は無視できません。
ロック: `VACUUM FREEZE` は、テーブル全体に対してロックを取得します。これにより、処理中は書き込み操作がブロックされる可能性があります。
CPU負荷: XIDのチェックや更新処理自体にもCPUリソースが消費されます。

トラブルシューティングのヒント:

1. `pg_stat_user_tables` を監視する:
このビューで、各テーブルの `age`（タプルのXIDの古さ）を確認しましょう。`age` が `XID_WRAPAROUND_THRESHOLD` に近づいているテーブルがないか、定期的にチェックすることが重要です。

SELECT relname, age(datfrozenxid, c.oid) AS dat_age, age(relfrozenxid) AS rel_age
FROM pg_class c
JOIN pg_database d ON d.oid = pg_class.relnamespace
WHERE relkind = ‘r’ AND relname NOT LIKE ‘pg_%’
ORDER BY rel_age DESC
LIMIT 10;

（注: 上記クエリは例であり、実際の運用ではより洗練された監視が必要です。）

2. `autovacuum` の設定を見直す:
`autovacuum` が適切にチューニングされていないと、XIDの周回が迫っているのに `VACUUM FREEZE` が実行されない、という事態が発生し得ます。`autovacuum_vacuum_threshold` や `autovacuum_vacuum_scale_factor` だけでなく、`autovacuum_freeze_max_age` の設定も重要です。これを低く設定しすぎると、過剰な `VACUUM` が発生する可能性もありますが、XID周回を防ぐためには、ある程度低い値に設定しておくことが推奨されます。

3. 手動での `VACUUM FREEZE` の実行:
緊急時や、`autovacuum` が期待通りに動作しない場合に、手動で `VACUUM FREEZE` を実行する必要が出てくるかもしれません。

VACUUM (FREEZE, VERBOSE) your_table_name;

ただし、これはリソースを大量に消費する可能性があるため、実行タイミングや影響範囲を慎重に検討する必要があります。本番環境での実行は、十分なテストと準備の上で行ってください。

4. `pg_xact` の確認:
`pg_xact` ディレクトリ（PostgreSQLのデータディレクトリ内）には、トランザクションのコミット状態が記録されています。このファイルが肥大化している場合も、XID管理に問題がある可能性を示唆します。

まとめ：安定稼働のための継続的な監視と理解

PostgreSQLにおけるXIDの周回問題と `VACUUM FREEZE` は、データベースの「寿命」に関わる、非常に根本的なテーマです。これを理解することは、単にエラーメッセージに対処するだけでなく、データベースの内部構造を深く理解し、より安定した、パフォーマンスの高いシステムを構築するための基礎となります。

`autovacuum` を適切に設定し、日頃からXIDの年齢を監視する習慣をつけることで、XID周回による「システム停止」という最悪の事態を回避できるはずです。

皆さんのPostgreSQL運用が、より安定的で、そして何よりも「安心して」運用できるようになることを願っています。また、何か深い掘り下げが必要なテーマがあれば、いつでもお声がけください。データベースの海は、まだまだ広いですからね。