【実務・中級編】トランザクションID (XID) – PostgreSQL

「PostgreSQLのトランザクションID（XID）が枯渇する」

この言葉を聞いて、背筋に冷たいものが走った経験はありませんか？もしあなたがDBA（データベース管理者）として現場に立っているなら、一度は耳にしたことがあるはずの恐怖です。

今日は、PostgreSQLの心臓部の一つ、「XID（トランザクションID）」と、それが引き起こすかもしれない「ラップアラウンド」という名の悪夢、そしてそれを防ぐための「凍結（Freezing）」について、現場の知見を交えて深掘りしていきましょう。

—

PostgreSQLにおいて、すべてのトランザクションには一意のIDが割り振られます。これがXIDです。

PostgreSQLはMVCC（多版型同時実行制御）を採用していますよね。データが更新されたとき、DBは「古い行を消して新しい行を書き換える」のではなく、「古い行に『無効』のフラグを立てて、新しい行を別に追加する」という手法をとります。

このとき、「どのトランザクションが、どの行を書き換えたのか？」を識別するために使われるのが32ビットの整数値、XIDです。

— 現在のトランザクションIDを確認してみる
SELECT txid_current();

これを見ると、数字が一つ増えているのがわかります。しかし、ここで一つの疑問が浮かびませんか？
「32ビットということは、約42億個（2^32）までしか数えられないよね？それって、DBを長く運用していたらすぐに足りなくなるのでは？」

その通り。これがXID枯渇問題の正体です。

—

もしXIDが上限に達したらどうなるか。PostgreSQLはIDを0にリセットして、再びカウントアップを始めます。

ここで問題になるのが、「過去のID」と「新しく割り振られたID」の比較です。DBは「どのトランザクションが古いか」を判断できなくなり、データが読み書き不能になる……これが「ラップアラウンド」によるDB停止のメカニズムです。

これを防ぐために、PostgreSQLには「凍結（Freezing）」という非常に賢いメカニズムが備わっています。

—

PostgreSQLは、ある一定期間を過ぎて「もう二度と変更される心配がない」と判断された古いトランザクションIDを、特別な値である`2`（`FrozenTransactionId`）に書き換えます。

この処理を「凍結」と呼びます。凍結された行は、すべてのトランザクションから「過去のデータ」として無条件に可視とみなされるようになります。

この凍結処理を裏で黙々とこなしているのが、実はみんなが嫌がる（？）`autovacuum`です。

`autovacuum_freeze_max_age` というパラメータの設定値に達すると、バキュームは「おっと、そろそろ凍結しないとまずいな」と判断して、古いテーブルをスキャンし、XIDをFrozenに書き換えます。

現場で「autovacuumが止まらない！負荷が高い！」と嘆くことがありますが、その裏側ではデータベースが自らの死（ラップアラウンド）を防ぐために必死で戦ってくれているというわけです。

—

ログに以下のような警告が出たら、迷わず手を動かしてください。

> “database ‘xxx’ must be vacuumed within ‘yyy’ transactions”

これは「もうすぐXIDが一周しちゃうよ！早く掃除して！」というDBからの悲鳴です。

1. まずは現在の状況を確認する
`pg_class`や`pg_database`を参照して、`relfrozenxid`の値を確認しましょう。

SELECT relname, age(relfrozenxid) as xid_age
FROM pg_class
WHERE relkind = ‘r’
ORDER BY xid_age DESC LIMIT 10;

ここで`xid_age`が異常に高いテーブルがあれば、それが犯人です。

2. 手動バキュームの実行
autovacuumが追いついていないなら、手動で`VACUUM FREEZE`をかけましょう。ただし、テーブルが巨大だとディスクI/Oが跳ね上がるので、トラフィックの少ない時間帯を狙うのが鉄則です。

—

XIDの管理は、まさにDBの「健康診断」です。
「バキュームはただのゴミ掃除」と思われがちですが、実は「DBの寿命を延ばす延命措置」でもあります。

大規模な更新が頻発するテーブルを持っているなら、`autovacuum_freeze_max_age`の調整や、適切なバキュームのスケジュール管理はエンジニアとして避けては通れない道です。

DBの深淵を覗くのは怖いかもしれませんが、仕組みさえ理解していれば恐れることはありません。今日の作業が終わったら、一度自分の担当しているDBの`relfrozenxid`を覗いてみてください。意外な発見があるかもしれませんよ。

それでは、また次回の記事でお会いしましょう！