PostgreSQL: XID周回問題に潜む別の問題

Copyright © 2015 NTT DATA Corporation

2015年5月30日株式会社 NTTデータ澤田雅彦

XID周回問題に潜む別の問題

PostgreSQLアンカンファレンス@Tokyo

2 Copyright © 2015 NTT DATA Corporation

自己紹介

澤田雅彦 @sawada_masahiko

NTTデータ基盤システム事業本部

• PostgreSQLの技術開発、技術支援に従事

• 今年PGCon行きます


INDEX

• XID周回とXID周回問題

• XID周回問題を防ぐ

• XID周回問題に潜む”別の問題”

• 解決に向けて


XID周回とXID周回問題

• 約40億トランザクション経過すると0に戻る(→XID周回)

• トランザクションID(XID)は4Byte

• ”過去の見えていたデータ”が、見えなくなってしまう(→XID周回問題)

• 約20億トランザクション経過すると発生。

• 例えば、200TPSのシステムだと、約115日で訪れる→年に3回発生

XID=100

過去 (見える)

未来 (見えない)

XID=100

過去 (見える)


見えない！

XID=100

過去 (見える)


INSERT。もちろん見える。

まだ見える。


XID周回問題を防ぐ

• タプルを凍結(FREEZE)

• FREEZEされたタプルはどのXIDよりも古い

• FREEZEする契機

• VACUUM/auto-vacuum/CLUSTER/VACUUM FULL

• auto-vacuumがXID周回問題防止VACUUMを自動で実施

• (残り1000万トランザクションでWARNING)

• (残り100万トランザクションでXIDの払い出しを禁止)

XID=100

過去 (見える)


XID=100

FREEZE

過去 (見える)


XID=100

FREEZE

過去 (見える)


FREEZEされてるので見える！

INSERT。もちろん見える。

まだ見える。 FREEZE処理実施。


XID周回問題は防げる。が、

• XID周回防止VACUUMはテーブルのフルスキャンが必要

• これは、更新が全くないテーブルでも必要

→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる

XID周回問題に潜む別の問題は、


XID周回問題は防げる。が、

• XID周回防止VACUUMはテーブルのフルスキャンが必要

• これは、更新が全くないテーブルでも必要

→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる

XID周回問題に潜む別の問題は、

”XID周回防止VACUUMに伴う大量のI/O”

ところで、なぜXID周回防止VACUUMはテーブルをフルスキャンする必要がある？


blkno lp vm_info t_xmin

0 1 BIT 60(FREEZE)

0 2 BIT 151

1 1 50(FREEZE)

1 2 52(FREEZE)

2 1 BIT 100

2 2 BIT 100

2 3 BIT 101

3 1 90(FREEZE)

3 2 101

4 1 BIT 120(FREEZE)

なぜテーブルをフルスキャンする必要がある？

通常のVACUUMはVisibility Mapにより飛び飛びに実行されることで、

テーブルのrelfrozenxidを更新できないため。

• pg_class.relfrozenxid : FREEZEされていない最小のXID

• XID周回防止VACUUMの必要性は主にrelfrozenxidの値で判断

relfrozenxid

100

: スキップされるブロック


解決に向けて

CF9.6でパッチ出してます(★の所)

• XIDを8Byteにする

• XIDをLSNを結びつける

• ★Read-Only Table

• ★すべてのタプルがFREEZEされたページを覚えておく

10


VisibilityMapにビットを追加

• これまでは、VMは1ページ当たり1ビットで管理

• ページ内のタプルが全てのトランザクションから見える(all-visible)→ビットを立てる

• ビットが立っているページはVACUUM(ゴミ掃除)不要

• VMに1ビットを追加する

• つまり1ページ当たり2ビット(all-visible, all-frozen)で管理。CLOGみたいな感じ。

• ページ内のタプルが全てFREEZEされている(all-frozen)→ビットを立てる

• ビットが立っているページはVACUUM(タプルFREEZE)不要

• VACUUM(タプルFREEZE)でページをスキップしてもrelfrozenxidを更新できる

9.6ではどちらのVACUUMも高速になる！かも！

11


まとめ

• PostgreSQLは更新のないテーブルにも、

定期的にフルスキャン(VACUUM)が走ります。

• 計画的なVACUUM FREEZEである程度防止できる

• 9.6で問題が解決するかも



Please Review the Patch.

Technology

PostgreSQL: XID周回問題に潜む別の問題